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ABSTRACT 


This  final  technical  report  includes  a  short  Executive  Summary  which  summarizes 
important  management  and  administrative  aspects  of  this  42-month  project,  including  a 
brief  chronology  and  an  accounting  for  the  funds  by  major  cost  category.  The  rest  of 
-the  report  presents  a  detailed  description  of  the  major  product  of  this  project,  a  com¬ 
puter  hardware/software  system  called  the  Intelligent  Array  System  (MS).  The  IAS 
processes  data  from  two  high-frequency  arrays  (NORESS  &  ARCESS)  in  Norway  to 
detect,  locate  and  identify  seismic  events.  The  MS  computers  and  functions  are  distri¬ 
buted  between  the  NOf  SAR  Data  Analysis  Center  (NDAC)  near  Oslo  and  the  Center 
for  Seismic  Studies  (Center)  in  Arlington,  VA.  The  MS  modules  at  NDAC  automati¬ 
cally  retrieve  data  fi-om  a  disk  buffer,  detect  signals,  compute  signal  attributes  (ampli¬ 
tude,  slowness,  azimuth,  polarization,  etc.),  and  store  them  in  a  commercial  relational 
database  m^agement  system  (DBMS).  MS  makes  scheduled  (e.g.,  hourly)  transfers  of 
the  data  to  a  separate  DBMS  at  the  Center.  Arrival  of  new  data  automatically  initiates 
a  "knowledge-based  system"  (KBS)  which  interprets  these  data  to  locate  and  identify 
(earthquake,  mine  blast,  etc.)  seismic  events.  This  KBS  uses  general  and  area-specific 
seismological  knowledge  represented  in  rules  and  procedures.  For  each  event,  unpro¬ 
cessed  data  segments  (e.g.,  7  minutes  for  regional  events)  are  retrieved  from  NDAC 
for  subsequent  display  and  analyst  review.  The  interactive  analysis  modules  include 
integrated  waveform  and  map  display/manipulation  tools  for  efficient  analyst  validation 
or  correction  of  the  solutions  produced  by  the  automated  system.  Another  KBS  com¬ 
pares  the  analyst  and  automatic  solutions  to  mark  overruled  elements  of  the  knowledge 
base.  Performance  analysis  statistics  guide  subsequent  changes  to  the  knowledge  base 
so  it  improves  with  experience.  " _ ^ 

The  IAS  is  implemented  on  networked  Sun  workstations,  with  a  56kbps  satellite 
link  bridging  the  NDAC  and  CSS  LANs.  The  software  architecture  is  modular  and 
distributed,  with  processes  communicating  by  messages  and  sharing  data  via  the 
DBMS.  The  MS  processing  requirements  are  easily  met  with  major  processes  (i.e.,  sig¬ 
nal  processing,  expert  system,  DBMS)  on  separate  Sun  4/2xx  workstations.  This 
architecture  facilitates  future  expansion. 
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EXECUTIVE  SUMMARY 


This  is  the  final  report  on  DARPA  Contract  MDA903-87-C-0037.  This  summary  describes  the 
important  management  and  administrative  aspects  of  the  contract  In  particular,  we  summarize 
the  chronology  of  the  contract  effort  and  relevant  events  that  occurred  before  and  after  this 
contract  Also,  we  summarize  the  allocation  of  funds  by  major  cost  categories. 

The  technical  report  that  follows  this  EXECUTIVE  SUMMARY  is  a  detailed  description  of  the 
major  deliverable  item  produced  by  this  contract,  the  Intelligent  Array  System.  The 
organization  of  this  report  is  described  in  Section  I  ("INTRODUCTION"),  particularly  Section 
1.4  ("Document  Organization"). 

CHRONOLOGY 


RELEVANT  PRE-CONTRACT  EVENTS 


1  Jan  86  Phase  I  Seismic  Array  Signal  Processing  System  Proposal 

SAIC  and  subcontractor  Advanced  Decision  Systems  (ADS)  proposed  (in  response 
to  DARPA/DSS-W  RFP  MDA903-86-R-0023)  a  six-month  project  to  design  a 
computer  hardware/software  system  to  detect,  locate,  and  characterize  seismic 
events  using  data  from  a  network  of  small  arrays. 

1  Mar  86  SAIC  &  ADS  Phase  I  Contract  Begins 

Two  Phase  I  contractors  were  selected,  with  the  other  team  being  Ensco  and 
subcontractor  Teknowledge  Federal  Systems  (TFS).  The  SAIC  funding  was 
$350,000  under  Contract  MDA903-86-C-0074. 

Sep  86  Phase  I  Completed 

SAIC  &  ADS  submitted  the  "Phase  I  Final  Report  and  Phase  II  Implementation 
Plan"  which  served  as  a  proposal  for  the  contraa  now  completed  with  this  Final 
Report.  A  two-day  briefing  summarizing  this  375  page  design  description  and 
project  plan  was  presented  to  a  DARPA  selection  panel,  including  computer 
demonstrations  of  prototypes  of  key  system  elements. 

26  Nov  86  Selection  and  Proposal  Revision 

SAIC  was  selected  as  prime  contractor  and  directed  to  submit  a  revised  proposal 
including  a  subcontract  for  complementary  tasks  to  be  done  by  Ensco  (with  TFS  as 
subcontractor  to  Ensco).  The  first  task  in  the  project  was  directed  to  be 
development  of  a  revised  plan  to  include  these  complementary  tasks. 

CONTRACT  CHRONOLOGY 


1  Jan  87  Pre-Contract  Cost  Authorization 

Limited  effort  began  on  DSS-W  authorization  to  accumulate  some  pre-contract 
costs  that  would  be  allowable  should  final  contractual  agreement  be  reached." 

1  Apr  87  Effective  Date  of  Contract  MDA903-87-C-0037 

The  contract  was  funded  at  $5,061,601  for  24  months  (ending  31  March  1989), 
including  $1,440,979  for  the  directed  subcontract  to  Ensco/TFS.  The  funded 
system  was  to  acquire  its  data  from  an  interface  at  the  Center  for  Seismic  Studies 
(i.e.,  transmission  to  the  Center  was  external  to  the  system). 


li 


22  Oct  87 


9  Feb  88 


Jun  88 


30  Sep  89 


Sep  89 


30  Sep  90 


DSS-W  Directs  Changes  to  the  Scope  of  Work 

The  effort  under  several  tasks  was  expanded  to  include  R&D  to  be  conducted  by 
research  staff  resident  at  the  Center  for  Seismic  Studies. 


SAIC  submitted  a  proposal  specifying  the  cost  for  the  directed  changes  listed 
above  and  a  number  of  other  extensions  to  the  scope  of  work  on  the  contract 

Contract  Modified  and  Extended 

The  change  proposal  was  funded  with  tasks  as  follows;  (1)  R&D  by  Center  staff 
(as  directed  in  October  1987);  (2)  Move  the  data  interface  to  the  NORSAR  facility 
(requiring  additional  computers  and  software  and  the  acquisition,  installation,  and 
maintenance  of  a  telemetry  link  to  Norway);  (3)  Installation  of  a  situation  room  at 
the  Center  (primarily  construction,  but  includes  some  software);  (4)  Development 
of  an  "Executive  Review  Station"  to  summarize  results  for  off-site  executives;  (5) 
Integration  of  a  capability  to  display  and  manipulate  satellite  imagery  from  SPOT; 
(6)  Additional  effort  to  acquire  seismological  knowledge  to  be  added  to  the 
system;  (7)  Publication  of  a  quarterly  newsletter  (The  Monitor)  summarizing  new 
technology  advances  in  the  NMRO  program.  To  complete  these  tasks  the  contract 
was  extended  to  30  September  1989.  The  modified  contract  was  funded  at 
$7,805,620  for  its  30-month  duration. 

Delivery  of  IAS  to  Center  for  Seismic  Studies 

The  MS  is  the  major  deliverable  on  this  contract,  and  it  was  delivered  in  final  form 
by  the  scheduled  end  of  the  contract. 

Performance  Extension  for  12  Months 

SAIC  requested  and  was  granted  a  12-month  extension  to  the  period  of 
performance  of  the  contract  at  no  cost  to  the  government.  This  extension  was  for 
a  modest  effort  to  complete  the  "Executive  Review  Station"  and  some  other  minor 
tasks. 

Official  End  of  Contract  MDA903-87-C-0037 

This  Final  Contract  Report  completes  all  deliverables  on  the  contract. 


1  Oct  89 


1  Jan  90 


Under  a  separate  contract,  the  Center  commenced  full-time  operation  of  MS  on  this 
date.  The  system  was  operated  continuously  for  8  weeks,  and  the  results  of  this 
operational  test  have  been  published  in  contract  reports  and  a  BSSA  paper. 

MS  Delivery  to  NORSAR 

Under  a  separate  contract,  MS  was  delivered  to  NORSAR.  From  shortly  after  this 
date  to  the  present  (October  1990)  MS  has  been  operated  continuously  by  the 
NORSAR  staff  to  produce  a  bulletin  of  regional  seismicity  recorded  by  the 
NORESS  and  ARCESS  arrays.  MS  is  used  to  produce  the  Norway  data 
contributed  to  the  data  exchange  experiments  conducted  under  the  auspices  of  the 
UN  Conference  on  Disarmament. 


The  reports  and  papers  describing  the  results  produced  by  MS  demonstrate  that  it  represents  a 
substantial  advance  in  the  state-of-the-art  for  seismic  data  analysis.  Further,  the  operational 
history  indicated  by  these  "post-contract  events"  demonstrates  that  the  system  is  robust  and 
economical  to  operate  and  maintain. 


FUNDING 

The  estimated  expenditure  of  contraci  funds  (based  on  costs  shown  by  SAIC  accounting  plus 
committed  expendituu'-  not  yet  included)  is  as  follows;^ 

$2,529,988  SAIC  system  design,  software  development,  system  integration,  and  project 
management 

$1,246,726  Purchase  and  maintenance  (through  30  September  1989)  of  computer  hardware 

$  44,732  Installation  of  telemetry  between  the  NORSAR  Data  Analysis  Center  (NDAC) 

and  the  Center  for  Seismic  Studies  (Center) 

$  71,855  Lease  of  communication  circuit  between  NDAC  and  the  Center 
$  927,651  R&D  by  research  staff  at  the  Center  for  Seismic  Studies 
$  98,444  Purchase  of  imagery  from  SPOT  Image  Corporation 

$  327,513  Construction  of  situation  room  at  the  Center  (including  projectors  and  sound 
system) 

$  84,359  Publish  four  issues  of  The  Monitor 

$1,440,775  Ensco  subcontract  (includes  subcontract  to  TFS) 

$  762,638  ADS  subcontract 

$  23,550  Inference  Corporation  subcontract  (evaluate  application  of  ART  to  this  problem) 

$  25,000  Columbia  University  subcontract  (upgrade  and  deliver  to  the  Center  a  version  of 

the  Lamont  SunPick  program  for  waveform  analysis) 

$  219,152  Administrative  costs  and  SAIC  fee  for  the  four  subcontracts 


$7,803,042  Total 


^  In  most  cases  the  SAIC  fee  is  included  in  the  total  cost.  The  exceptions  are  the  subcontracts  for 
which  we  list  .separately  the  subcontractor  funding  and  the  SAIC  administrative  costs  and  fee. 
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I  INTRODUCTION 


1.1.  BACKGROUND 

The  Intelligent  Array  System  (IAS)  was  developed  to  meet  the  data  analysis  challenge  posed  by 
the  small  high-frequency  seismic  arrays  developed  by  Norwegian  and  American  scientists  in 
the  mid-1980’s.  The  first  of  these  arrays  (NORESS)  was  completed  in  1985  and  the  nearly 
identical  ARCESS  array  was  completed  in  1987.  Figure  1.1  shows  the  array  locations  and 
geometry  (see  Mykkeltveit,  1985,  Mykkeltveit  et  al.,  1987  for  details). 

The  overall  objective  for  these  arrays  is  to  provide  an  improved  capability  to  detect  and 
identify  underground  nuclear  explosions;  that  is,  an  improved  seismic  monitoring  capability. 
The  focus  of  seismic  monitoring  R<feD  since  the  mid-1960’s  had  been  on  teleseismic 
monitoring,  in  large  part  due  to  that  stations  being  sparse  or  absent  at  regional  distances  from 
areas  of  primary  interest  (e.g.,  the  Soviet  Union).  Also,  tele.seismic  signals  are  very  much 
simpler  and  easier  to  interpret  titan  the  complex,  high  frequency  signals  seen  at  regional 
distances.  But  several  reinforcing  factors  combined  at  the  beginning  of  the  1980’s  to  shift  the 
focus  toward  seismic  monitoring  at  regional  di.stances.  Teleseismic  monitoring  technology  had 
matured  to  the  point  that  detection  and  identification  capability  were  reaching  their  physical 
limits.  At  the  same  time,  improved  seismic  instrumentation  and  electronics  allowed  the 
sensitive  recording  of  the  much  higher  frequencies  seen  in  regional  signals,  offering  the 
opportunity  to  exploit  this  information  for  event  identification.  Finally,  Soviet  resistance  to  the 
installation  of  stations  inside  their  borders  began  eroding  in  the  late-1970’s  (during  the 
comprehensive  test  ban  treaty  negotiations  that  were  recessed  in  1978),  and  now  U.S.  stations 
are  being  installed  in  the  Soviet  Union  under  scientific  exchange  agreements.  Thus,  during  the 
1980’s,  detecting  and  identifying  the  small  events  recorded  by  a  regional  seismic  networic 
became  the  key  technical  issue  for  advancing  seismic  monitoring  capability. 

Small  apxjrturc  regional  arrays  like  NORESS  and  ARCESS  provide  a  major  step  forward  in 
seismic  data  recording  technology,  since  they  detect  regional  signals  from  all  but  very  small 
nuclear  explosions.  For  example,  a  1  KT  nuclear  explosion  is  expected  to  produce  a 
magnitude  of  about  2.5,  and  the  NORESS  array  has  been  shown  to  detect  90%  of  the  events  of 
this  size  occuring  to  beyond  1000  km  (Ringdal,  1986).  But  signal  detection  is  only  the  first 
step,  and  the  real  challenge  is  to  use  the  detected  signals  to  locate  events  accurately  and  to 
distinguish  underground  nuclear  explosions  from  the  many  earthquakes  and  industrial 
explosions  also  detected  by  the  network. 

The  IAS  provides  a  new  generation  of  .seismic  data  analysis  technology  to  exploit  the  full 
p)otential  of  the  sensitive  new  regional  arrays.  It  builds  upon  work  done  by  the  NORSAR  staff 
to  adapt  and  extend  well-proven  techniques  used  to  analyze  teleseismic  data  from  the 
NORSAR  array.  A  notable  accomplishment  is  the  RONAPP  program  (Mykkeltveit  and 
Bungum,  1984)  which  processes  NORESS  data  to  produce  a  list  of  detected  signals  and 
located  events.  RONAPP  combines  automatic  beamforming,  signal  detection  and  post¬ 
detection  (f-k  spectrum  is  most  important)  p  ocesses  with  a  few  rules  incorporating  knowledge 
about  the  robust  behavior  of  signals  in  that  region  to  locate  events  defined  by  pairs  of 
associated  Pn  and  Lg  phases.  This  program  represents  a  significant  advance  in  capabilities  for 
automatic  production  of  a  seismic  bulletin.  However,  further  improvement  of  Uie  automated 
processing  requires  a  richer  representation  of  the  seismological  knowledge  used  by  human 
analysts  and  techniques  that  extend  to  networks  of  arrays  and  non-array  stations.  IAS  meets 
these  requirements. 
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Figure  l.i.  The  locations  and  array  geometry  for  NORESS  and  ARRESS  arrays.  The  two 
arrays  are  essentially  identical,  each  having  24  elements  in  four  concentric  rings  (A,  B.  C,  D) 
plus  a  center  element  (hub).  The  diameter  of  the  outer  (D)  ring  is  3.0  km.  There  are  3- 
component  seismometers  at  the  hub  and  three  of  the  seven  sites  in  the  C-ring.  (Figure  provided 
by  Frode  Ringdal,  NORSAR) 
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12.  CONCEPT 

The  fundamental  concept  for  IAS  is  illustrated  in  Figure  1.2.  The  central  element  is  a 
computer  system  which  automatically  interprets  seismic  data  to  detect,  locate  and  identify  all 
interesting  seismic  events.  The  automatic  inierpretadon  is  reviewed  and  validated  by  a  human 
analyst.  This  validation  provides  a  metric  for  measuring  the  performance  of  the  "automatic 
analysis,"  which  is  a  key  part  of  the  concept  for  acquiring  new  knowledge  to  make  the  system 
performance  match  more  closely  that  of  the  analyst.  Also,  there  are  independent  R&D 
activities  at  many  institutions  which  provide  ncvv  knowledge  and  processing  techniques  that 
can  improve  the  performance  of  the  automated  system. 

The  purpose  of  IAS  is  detect,  locate,  and  identify  regional  seismic  events,  and  (1)  the  results 
are  to  be  as  reliable  as  the  physics  will  allow,  and  (2)  the  methods  are  to  be  as  automated  as 
technology  will  allow.  Therefore,  the  automated  processing  must  repre.scnt  the  complex  area- 
specific  knowledge  applied  by  human  analysts,  and  the  system  must  be  designed  to  facilitate 
the  acquisition  and  incortxiration  of  iiew  knowledge.  For  these  reasons  the  use  of  "expen 
stems"  technology  cernral  to  the  design  concept  for  IAS. 


13.  ARCHITECTURE 

The  overall  architecture  of  IAS  is  shown  ir  Figure  1.3.  The  raw  data  horn  the  arrays  is 
automatically  recorded  and  transmitted  to  the  NORSAR  Data  Analysis  Center.  At  NORSAR 
the  seismic  data  arc  separated  from  the  maintenance  (statc-of-hcalth)  data,  checked  for  validity, 
and  stored  on  a  magnetic  disk.  The  IAS  system  then  automatically  acquires  the  data  from  the 
disk  and  begins  its  processing.  Since  only  about  10%  of  th-'  data  include  sci.'mic  signa’s,  the 
IAS  system  docs  the  oata-intensive  signal  processing  near  the  source  of  tfic  data  at  I.ORSAR. 
The  knowledge-rich  interpretation  is  done  at  the  Center  for  Seismic  Studies  in  Arlington,  VA.t 
The  computers  are  in  constant  communicatio.n  across  the  satellite  link  between  these  two  sites, 
much  as  if  they  were  at  the  same  site.  Most  of  the  software  development  was  done  at  the 
S.\IC  facilities  in  San  Diego.  Computers  at  the  three  sites  shown  in  the  figure  are  linked  by  a 
UNIX  wide-area  network  bridge  (WAN).  This  allows  near!  transparent  access  to  computers 
anywhere  on  the  network,  and  nearly  all  the  software  installation  and  testing  at  all  tiirec  sites 
was  done  by  sL^ff  working  in  San  Diego. 


1.4.  DOCUMENT  ORGANIZATION 

This  introductory  section  provides  a  brief  summary  of  the  background  and  motivation  for 
developing  IAS,  the  fundamental  concept  underlying  the  des  gn,  and  a  high-level  view  of  the 
overall  architecture.  A  detailed  overview  of  the  system  is  provided  in  the  following  sections: 

Section  II  SYSTEM  OVERVIEW 

This  provides  a  conceptual  view  of  the  IAS.  The  emphasis  is  on  the  "expert 
system"  used  for  the  automated  processing  and  the  related  elements  used  to 
acquire  new  knowledge  to  be  added  to  the  expert  system. 

Section  III  SOFTWARE  ARCHITECTURE 

The  individual  software  modules  ("processes")  and  their  interaction  arc 
described. 


t  This  IS  the  basic  architecture  implemented  initially.  However,  an  imerpreiation  system  that  essential¬ 
ly  duplicates  the  system  at  the  Center  is  being  installed  at  NORSAR  for  independent  data  interpretation. 
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Figu  e  1.2.  The  underlying  concept  motivating  IAS. 


Figure  1.3.  The  overaU  architecture  of  IAS  is  illustrated  through  the  locations  of  the  two 
arrays  that  provide  data,  the  three  locations  involved  in  the  analysis  of  the  data,  and  the 
communication  links  among  them. 


Section  IV 

Section  V 
Section  VI 


FUNCnUNAL  DESCRIPTION 

The  system  is  described  from  the  seismological  perspective  in  this  section.  That 
is,  we  describe  the  algorithms  and  nnes  used  for  the  automated  processing  and 
the  functions  available  to  a  seismologist  interacting  with  the  system. 

HARDWARE  ARCHITECTURE 

This  provides  a  mapping  of  the  MS  software  modules  to  computers. 
PROCESSING  EXAMPLES 

An  excellent  shortcut  to  an  understanding  of  the  design  of  IAS  is  a  review  of  the 
processing  examples  presented  in  this  section. 
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2.1.  INTRODUCTION 

This  overview  of  the  Intelligent  Array  System  begins  with  a  description  of  the  major  software 
elements  of  the  system  in  Section  2.2.  The  central  element  is  the  "expert  system"  which 
locates  and  identifies  seismic  events  (Section  2.3).  As  discussed  in  Section  1,  the  major  reason 
for  introducing  expert  system  technology  is  to  provide  a  more  flexible  and  convenient 
framework  for  introducing  the  complex  region-specific  knowledge  needed  for  analyzing  seismic 
events.  For  this  we  must  acquire  the  appropriate  knowledge  in  an  appropriate  form,  and  our 
concept  for  this  "Knowledge  Acquisition"  is  described  in  Section  2.4.  We  conclude  this 
overview  with  a  somewhat  more-detailed  view  of  the  overall  architecture  shown  in  Figure  1.3. 


2.2.  MAJOR  ELEMENTS  OF  IAS 

The  major  elements  of  the  IAS  arc  shown  graphically  in  Figure  2.1.  The  functional  elements 
are  in  boxes,  and  the  key  data  objects  are  shown  between  vertical  lines.  The  solid  arrows 
indicate  the  dominant  direction  of  dataflow.  There  are  also  important  software  facilities  that  do 
not  fit  into  a  dataflow  diagram,  and  these  arc  shown  in  the  shaded  boxes  with  rounded  comers. 
Each  of  the  elements  in  Figure  2.1  will  now  be  described. 

Data  (data  objcctl 

All  seismic  data  collected  by  the  NORESS  and  ARCESS  arrays  are  provided  to  IAS.  These 
arrays  also  transmit  state-of-health  and  engineering  data  to  the  NORSAR  Data  Analysis  Center 
(NDAC)  where  they  are  handled  by  another  computer  system.!  The  seismic  data  are  stored  on 
NDAC  disks  by  software  developed  and  maintained  by  Science  Horizons,  Inc.  and  NORSAR. 

Data  Acquisition  (functional  element) 

This  software  element  acquires  the  data  from  the  NDAC  disks  as  it  is  needed  by  elements  of 
IAS. 

Signal  Processing  (functional  elementl 

The  first  IAS  process  is  to  detect  signals  and  extract  features  that  describe  them.  The  details  of 
the  signal  processing  are  described  in  Section  4.2.  It  includes  beamforming,  signal  detection, 
and  arrival  time  refinement.  The  segment  of  data  including  the  detected  signal  is  then 
processed  further  to  measure  the  features. 

Features  (data  object) 

Each  detected  signal  is  characterized  by  an  arrival  time  and  parameters  that  describe  its 
character.  These  parameters  describe  the  amplitude,  polarization,  and  spectrum.  The  f-k  power 
spectrum  is  computed  and  analyzed  to  estimate  the  azimuth  and  slowness  of  the  detected 
signal.  Sec  Section  4.2  for  more  details  about  these  "po.st-dctection"  calculations. 

Event  Location  (functional  clement) 

The  "expert  system"  described  in  Section  2.3  and  in  more  detail  in  Section  4.3  analyzes  the 


t  As  noted  severaJ  places  in  this  report  (e.g.,  sec  the  discussion  of  Figure  1.3),  there  is  an  intimate  link 
between  the  computers  at  the  NDAC  and  the  Center  that  blurs  the  distinction  between  IAS  and  non-MS 
software.  For  example,  the  MS  system  can  display  graphics  produced  by  other  systems  at  the  NDAC 
simultaneously  with  graphics  produced  by  MS  software. 
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Figure  2.1.  The  major  functional  elements  and  data  objects  in  IAS  arc  shown  with  solid 
arrows  indicating  the  dominant  direction  ol  dataflow.  The  key  software  facilities  used  to 
integrate  the  system  are  also  shown  at  the  left. 


detected  signals  and  their  features  to  locate  events. 

Location  (data  obiectl 

The  output  of  the  Event  Location  element  is  the  location  (including  confidence  limits),  details 
about  the  signals  used  to  form  this  location,  and  details  about  the  reasoning  leading  to  this 
solution. 

Event  Identification  (functional  element) 

Given  a  located  event,  the  "expert  system"  identifies  it  as  an  earthquake,  mining  explosion, 
nuclear  explosion,  or  some  other  type  of  seismic  event.  The  basis  for  this  identification  and  an 
estimate  of  confidence  in  its  validity  is  part  of  the  "identification.”  The  dotted  arrow  inside  the 
"expert  system"  in  the  figure  indicates  that  additional  signal  processing  is  often  done  during  the 
Event  Identification. 

Yield  Estimation  (functional  element! 

For  explosions  there  is  a  process  external  to  the  "expert  system"  which  estimates  the  yield. 
The  IAS  computes  seismic  magnitude  and  other  event  attributes  that  are  used  for  yield 
estimation.  S-Cubed  is  developing  a  comprehensive  yield  estimation  methodology  under  a 
separate  project. 

Interactive  Analyst  Review  (functional  elementl 

The  solutions  determined  by  the  "expert  system"  arc  reviewed  here  by  a  human  analyst  who 
validates  them,  making  corrections  as  necessary.  This  provides  quality  control  for  publication 
of  the  solutions  obtained  by  the  system.  It  also  provides  a  fundamental  clement  of  the  IAS 
concept  for  knowledge  acquisition. 

Knowledge  Acquisition  (functional  element) 

This  module  analyzes  results  from  the  automated  processing  and  corrections  made  by  the 
analyst  to  develop  new  knowledge  to  improve  the  performance  of  the  automated  processing. 
The  design  concept  is  described  in  Section  2.4. 

Knowledge  (data  object) 

With  the  aid  of  the  knowledge  acquisition  module,  new  knowledge  is  acquired  in  the  form  of 
the  rules  and  scripts  used  by  the  system. 

Graphics  Displays  (software  facility) 

These  displays  provide  the  man-machine  interface  for  op)erating  and  maintaining  the  system,  as 
well  as  for  reviewing  the  results  it  produces.  All  the  graphics  is  done  with  X-Windows.  The 
most  important  displays  emphasize  maps  and  waveforms  to  summarize  and  manipulate  results 
produced  by  the  system.  Also,  abstract  graphical  presentations  of  the  system  hardware  and 
software  architecture  simplify  operations  and  maintenance. 

Distributed  Processine  Manager  (software  facility) 

As  will  be  seen  in  Section  III,  the  MS  software  architecture  divides  the  system  into  nearly 
independent  processes  that  communicate  with  inter-process  communication  (IPC)  messages.  A 
Manager  process  is  used  to  manage  and  monitor  these  IPC  messages.  This  process  also 
provides  facilities  for  system  administration  (startup,  process  migration,  etc.) 

Database  Management  System  (software  facility) 

The  seismic  wayeform  segments  are  bulky  data  objects  managed  by  the  UNIX  file  system. 
Nearly  all  of  the  other  data  used  by  the  system  are  parameters  managed  by  a  relational 
database  management  system  (RDBMS)  which  is  INGRES  in  the  initial  implementation.  All 


SYSTEM  OVERVIEW 


9 


processes  using  parameter  data  write  and  read  data  directly  to  and  from  the  RDBMS. 


23.  OVERALL  ARCHITECTURE  OF  THE  IAS  EXPERT  SYSTEM 

The  shaded  area  in  Figure  2.1  shows  the  IAS  "expen  system."  The  distinguishing  features  of 
this  portion  of  the  overall  system  are: 

•  The  input  is  the  unprocessed  seismic  data. 

•  The  output  is  the  interpretation  of  the  data,  including  events  Qocation  and  identification), 
and  detected  seismic  phases  (associated  with  events  and  unassociated). 

•  The  processing  is  done  in  a  fully  automated  way,  with  no  human  intervention. 

In  this  section  we  provide  conceptual  view  of  this  architecture.  More  detail  appears  in  Section 
4.3. 

The  major  steps  in  the  automated  analysis  of  the  data  are  shown  in  Figure  2.2.  The  first  step 
is  signal  processing.  Tlie  full  incoming  data  stream  (the  "time  series")  are  input  to  this  module 
which  does  the  following  operations:! 

1.  Quality  Control  -  The  individual  channels  are  analyzed  to  detect  spikes,  dropouts,  and 
noise  bursts.  Faulty  time  segments  are  repaired  when  possible,  but  are  usually  deleted 
from  further  processing. 

2.  Beamforming  -  A  fixed  suite  of  filtered  beams  are  computed. 

3.  Signal  Detection  -  The  short-term  (STA)  and  long-term  (LTA)  average  amplitude  is 
computed  for  each  beam,  and  detections  are  declared  when  the  STA/LTA  exceeds  the 
detection  threshold  for  that  beam.  When  more  than  one  beam  threshold  is  exceeded, 
simple  rules  are  applied  to  select  one  as  the  "detecting  beam." 

4.  Onset-time  refinement  -  Segments  containing  detections  are  analyzed  to  refine  the  onset 
time  estimate,  with  details  of  the  analysis  depending  on  which  beam  is  the  "detecting 
beam." 

5.  Amplitude  and  period  estimation  -  The  amplitude  and  period  of  detections  are  computed 
using  preset  criteria  which  vary  with  detecting  beam. 

6.  Spectrum  calculation  -  The  spectrum  of  the  signal  and  a  previous  "noise"  segment  are 
calculated  according  to  rules  for  the  window  selection. 

7.  Polarization  analysis  -  The  available  three-component  data  are  subjected  to  polarization 
analysis  and  the  results  are  summarized  with  a  small  number  of  parameters. 

8.  f-k  calculation  -  The  frequency-wavenumber  calculation  is  done  for  a  several-second 
segment  of  data  around  the  detection  and  a  band  of  frequencies  around  the  dominant 
frequency  of  the  detection. 

9.  Azimuth  and  slowness  estimation  -  The  f-k  power  contours  are  analyzed  to  estimate  the 
azimuth  and  slowness  and  the  error  in  those  estimates. 

The  signal  processing  module  was  written  in  Fortran  during  the  IAS  project.  However,  many 
of  the  functional  subroutines  were  adopted  intact  or  adapted  from  NORSAR  programs  (see 
Section  4.2).  The  output  of  the  signal  processing  module  includes  detected  signals  and 


t  TTiese  operations  are  described  in  general  terms  here,  focusing  on  fixed  aspects  of  the  architecture. 
More  specific  design  information  is  provided  in  Section  4.2,  but  we  note  that  the  details  may  change  as 
the  system  evolves  and  improves. 
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Figure  2.2.  A  conceptual  view  of  the  IAS  expert  system  for  automated  location 
identification  of  seismic  events. 


parameters  describing  the  character  of  these  signals.  These  are  called  "features"  and  are  used 
to  locate  events. 

As  shown  in  Figure  2.2,  "rule-based  reasoning"  is  applied  to  the  "features"  to  identify  the 
phases,  associate  them  with  events,  and  compute  an  initial  location  for  each  event.  The  general 
organization  of  this  portion  of  the  "expert  system"  is  shown  in  Figure  2.3.  The  data  from  each 
array  are  first  processed  separately  to  obtain  "single  array  locations,"  and  the  three  major  steps 
in  that  processing  are  shown.  First,  each  signal  detection  is  classified  into  one  of  four  phase- 
types,  regional  P,  regional  S,  teleseism,  and  noise.  This  is  primaiily  based  on  the  slowness 
estimate,  though  other  information  (e.g.,  dominant  frequency)  can  be  introduced  into  the  rules 
when  it  is  helpful.  The  next  step  is  to  collect  the  phases  into  groups  that  appear  to  be  from  the 
same  event.  A  number  of  rules  are  used  to  do  this,  but  the  most  important  look  for  a  sequence 
of  phases  (with  P  before  S)  with  azimuths  that  overlap  (within  the  error  bounds).  The  initial 
hypothesis  is  that  all  phases  with  overlapping  azimuths  within  an  appropriate  time  window  are 
from  a  single  event.  Additional  rules  are  then  used  to  separate  the  sequence  into  groups  of 
phases  from  multiple  events  when  contradictions  to  the  single-event  hypothesis  are 
encountered. 

The  next  step  in  the  single  array  processing  is  to  associate  and  identify  individual  phases  in  the 
event  groups.  That  is,  particular  phases  are  identified  as  Pn,  Pg,  Sn,  Lg,  Rg,  or  remain  as  P  or 
S.  Any  two  regional  phases  are  adequate  to  compute  a  location  (using  the  technique  of  Bratt 
and  Bache,  1988)  when  each  phase  has  an  onset  time  and  azimuth. 

.Single  array  locations  generally  have  large  error  bounds,  which  is  easily  seen  by  noting  that  n° 
error  in  azimuth  translates  to  17.5n  km  error  in  location  at  a  range  of  1(XX)  km,  even  if  the 
range  is  estimated  perfectly.  If  a  phase  is  misidentified  (e.g.,  Sn  is  mistaken  for  Lg),  the 
location  will  be  grossly  inaccurate.  Thus,  association  with  even  a  single  measurement  from 
another  station  or  array  provides  a  major  improvement  in  the  location  accuracy.  For  this 
reason  "network  processing"  is  emphasized,  as  is  reflected  in  Figure  2.3. 

The  "network  processing"  is  conceptually  similar  to  the  automatic  association  procedures  used 
to  analyze  teleseismic  data  (e.g.,  Engdahl  and  Gunst,  1966;  Slunga,  1980).  The  "single  array 
locations"  provide  initial  location  hypotheses.  The  system  first  seeks  corroboration  of  the 
single  array  location  from  one  array  with  locations  and  individual  phases  at  the  second.  When 
no  corroboration  is  found,  the  system  backtracks  to  revise  the  single  array  locations  (including 
the  phase  identifications  and  associations),  then  tries  again  to  find  corroboration.  The 
backtracking  capability  is  indicated  in  the  figure  with  grey  two-headed  arrows.  During  this 
process,  hypothesized  solutions  can  also  be  checked  for  consistency  with  other  seismological 
knowledge  (e.g.,  amplitude  consistency). 

The  result  of  the  "network  processing"  is  an  "initial  location"  based  on  general  seismological 
knowledge  and  some  of  the  region-specific  knowledge  needed  to  associate  and  identify  phases 
(e.g.,  Lg  does  not  propagate  across  oceanic  paths,  Pg  is  generally  the  largest  amplitude  phase 
at  close  ranges,  etc.).  Referring  back  to  Figure  2.2,  refinement  of  the  location  using  knowledge 
gained  from  past  events  in  the  vicinity  is  the  next  step,  which  involves  "case-based  reasoning." 

In  "case-based  reasoning"  we  use  knowledge  gained  by  a  statistical  synthesis  of  features  fror 
a  past  events  (cases)  in  a  particular  area.  Generally,  the  events  arc  in  a  small  area;  often  thi 
are  repeated  explosions  in  a  single  mine.  There  are  three  somewhat  different  ways  thi 
knowledge  can  be  applied; 
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Figure  2.3.  The  rule-based  reasoning  from  "features"  to  an  "initial  location"  shown  i 
Figure  2.2  is  expanded  to  indicate  the  major  steps  in  the  reasoning  process. 


•  The  location  is  refined  by  recomputing  it  relative  to  the  location  of  past  events.  This  is 
an  implementation  of  "master  event"  methods  (e.g.,  Douglas,  1967;  Jordan  and  Sverdrup, 
1981)  within  the  context  of  this  system. 

•  The  features  from  the  "initial  location"  (apart  from  travel-time  and  gross  amplitude 
consistency  which  are  considered  at  an  earlier  stage)  can  be  so  different  from  those 
expected  in  the  area  that  the  "initial  location"  is  rejected  (i.e.,  backtracking  is  initiated  to 
find  a  better  solution).! 

•  An  event  is  seen  to  be  so  similar  to  a  particular  class  of  past  events  (e.g.,  events  in  a 
mine)  that  it  can  be  said  with  confidence  to  be  another  instance  of  that  class.  For  mines 
that  are  independently  located  (e.g.,  by  overhead  photography)  this  provides  a  location 
more  accurate  than  is  possible  with  travel-time  and  azimuth  data  from  a  few  arrays.  It 
also  provides  powerful  evidence  for  identifying  the  event. 

Implementation  of  "case-based  reasoning"  for  the  latter  two  involves  pattern  matching.  The 
specific  pattern  recognition  scheme  applied  in  IAS  is  described  in  Section  4.2.  The  basic 
concept  is  to  select  a  set  of  parameters  characterizing  events  in  the  region  of  interest.  The 
mean  value  and  its  variance  are  determined  statistically.  New  events  are  compared  to  this 
pattern  of  parameters  (called  a  "script"  in  IAS)  and  the  closeness-of-fit  is  calculated.  Rules  are 
used  to  develop  conclusions  from  the  closcness-of-fit  metric.  The  method  is  sensitive  to  the 
selection  of  parameters  included  in  the  script,  the  weighting  of  these  parameters,  the  events 
("cases")  used  to  compute  the  script,  the  closeness-of-fu  metric,  and  the  rules  used  to  interpret 
this  metric.  Thus,  much  experience  and  many  cases  mu.sl  be  accumulated  to  make  effective 
use  of  this  method  for  the  latter  two  applications  of  "case-based  reasoning." 

After  applying  this  area-specific  knowledge,  we  have  a  "refined  location."  The  next  step 
(Figure  2.2)  is  to  identify  the  event.  Of  course,  the  crucial  objective  is  to  identify  underground 
nuclear  explosions,  but  these  are  rare  in  the  region  covered  by  the  NORESS  and  ARCESS 
arrays.  Also,  the  basic  approach  to  event  identification  is  to  isolate  for  closer  scrutiny  a  small 
number  of  "unidentified"  events  which  might  be  nuclear  explosions  by  positively  identifying  as 
many  events  as  possible.!  So  the  dominant  technical  problem  for  IAS  is  to  identify  earthquakes 
and  industrial  explosions  occuring  within  the  zone  of  regional  coverage  of  the  two  arrays.  In 
this  zone  industrial  explosions  are  much  more  common,  especially  in  that  portion  that  lies 
within  the  Soviet  Union. 

As  indicated  in  Figure  2.2,  event  identification  involves  both  rule-based  and  case-based 
reasoning.  The  latter  was  described  above.  For  example,  we  identify  (with  a  measure  of 
confidence)  an  event  as  a  mine  explosion  because  its  signals  are  like  those  from  previous 
explosions  in  that  mine.  The  problem  is  to  separate  signal  characteristics  indicative  of 
explosions  in  the  mine  from  those  that  merely  indicate  an  event  in  the  vicinity  of  the  mine. 

The  simplest  application  of  rule-based  reasoning  for  event  identification  is  to  identify  the  event 
based  on  its  location.  As  one  example,  depth  identifies  earthquakes.  Also,  location  is  often 
the  best  indication  that  an  event  is  not  a  nuclear  explosion  (e.g.,  it  is  in  the  Baltic  Sea).  For 
events  not  identified  by  location  or  similarity  to  previous  events,  the  identification  must  be 
based  on  other  characteristics  of  the  seismic  signals,  vs  shown  in  Figure  2.2,  this  often 
requires  more  signal  processing.  For  example,  we  compute  the  cepstrum  and  analyze  it  for 
peculiar  characteristics  of  mining  explosions  (e.g.,  Baumgardt  and  Ziegler,  1988).  Numerous 

!  Technically,  it  is  much  easier  to  say  with  certainty  that  an  event  is  not  a  nuclear  explosion  than  the 
converse.  For  example,  we  know  an  event  deeper  than  a  few  kilometers  is  not  a  nuclear  explosion. 
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other  techniques  have  been  suggested  involving  spectral  ratios,  phase  amplitude  ratios,  etc.,  and 
the  particular  set  implemented  in  /AS  is  described  in  Section  4.5.  Combining  the  evidence 
from  these  techniques  is  a  straightforward  application  of  rule-based  reasoning.  Since  this  is  a 
difficult  and  unsolved  problem,  the  details  of  the  implementation  are  expected  to  change  as 
experience  accumulates. 

The  final  stage  shown  in  Figure  2.2  is  to  "Display,  Review,  Archive"  the  results.  These 
functions  are  external  to  the  "expert  system"  and  arc  described  in  a  different  way  in  Figure  2.1. 
Conceptually,  the  most  important  external  function  is  the  knowledge  acquisition  described  in 
the  next  section. 


2.4.  KNOWLEDGE  ACQUISITION 

The  operational  concept  for  MS  includes  review  and  validation  of  all  automated  solutions  by  a 
skilled  human  analyst,  and  the  MS  includes  extensive  capabilities  for  rapid  and  accurate  analyst 
review.  The  significance  for  quality  assurance  is  obvious,  but  interactive  analyst  review  also 
provides  the  baseline  needed  for  the  acquisition  of  new  knowledge  to  improve  the  expert 
system  performance.  The  MS  concept  for  knowledge  acquisition  is  expressed  in  a  module 
called  the  "knowledge  acquisition  station"  or  KAS  (Figure  2.1).  The  functions  of  the  KAS 
include: 

•  Explanation  -  Explain  the  decision  process  leading  to  each  solution  developed  by  the 
expert  system. 

•  Performance  Validation  -  Compare  the  performance  of  the  expert  system  with  "correct" 
solutions  obtained  by  a  human  analyst  and  annotate  them  accordingly. 

•  Performance  Analysis  -  Provide  statistics  and  other  summary  information  to  identify 
deficient  elements  of  the  knowledge  base  and  select  representative  examples  using  those 
knowledge  base  elements. 

•  Knowledge-Base  Augmentation  -  Add  new  knowledge  to  the  knowledge  base. 

•  Knowledge-Base  Validation  -  Conduct  tests  to  ensure  that  the  augmented  knowledge  base 
leads  to  improved  performance  by  the  expert  system. 

The  requirements  for  these  functions  arc  a  major  reason  that  expert  systems  technology  is 
being  used  in  IAS.  We  emphasize  that  there  are  some  important  features  of  this  problem  which 
require  an  unconventional  (compared  with  most  "expert  systems")  approach  which  integrates 
elements  of  our  expert  system  with  a  relational  database  management  system  (RDBMS).  Most 
expert  systems  provide  explanation,  and  this  can  be  as  elaborate  as  needed  while  the  relevant 
data  remain  resident  in  the  expert  system  memory  structures.  However,  in  IAS  most  requests 
for  explanation  arc  expected  to  occur  long  after  the  processing  is  completed.  More  important, 
most  useful  seismological  knowledge  requires  recognition  of  patterns  in  many  events  rather 
than  details  about  a  few  particular  events.  Thus,  performance  analysis  requires  a  synthesis  of 
experience  accumulated  over  time. 

The  IAS  concept  for  knowledge  acquisition  is  sketched  in  Figure  2.4.  The  key  innovation  in 
this  concept  is  the  caching  of  "audit  records"  in  tables  in  the  relational  database  management 
system  ("database").  These  "audit  records"  are  written  by  the  "expert  system"  to  describe  the 
decision  process  and  identify  the  specific  rules  that  led  to  key  decisions.  The  full  panoply  of 
relational  database  search  and  retrieval  tools  can  then  be  used  to  organize  and  synthesize  the 
information  in  the  audit  trail  and  other  tables  describing  the  event.  The  major  disadvantage  of 
this  approach  is  that  the  audit  trail  is  incomplete,  since  not  all  decisions  can  be  represented 
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Figure  2.4.  TTic  IAS  concept  for  knowledge  acquisition. 


within  a  relational  database  framework.  In  cases  where  more  information  is  needed,  tlie  data 
can  be  reprocessed  by  the  expert  sy.^tcm  to  obtain  a  complete  explanation. 

As  indicated  in  Figure  2.4,  all  "expert  system"  solutions  are  reviewed  by  a  human  analyst  who 
validates  correct  solutions  and  corrects  invalid  solutions  using  a  suite  of  ir’eractive  tools 
provided  for  this  purpose.  Linked  with  the  interactive  analyst  review  module  is  the 
performance  validation  module,  which  is  itself  an  expcn  system.  When  the  analyst  validates 
or  corrects  a  solution,  a  message  describing  that  action  is  passed  to  the  performance  validation 
module.  This  module  u.ses  rule-ba.sed  reasoning  to  identify  those  elements  of  the  decision 
process  that  have  been  validated  or  implicitly  invalidated  by  a  correction.  The  corresponding 
audit  records  are  updated  with  this  information. 

The  performance  analysis  module  includes  database  sorting  and  manipulation  tools  to  organize 
and  analyze  the  information  about  the  performance  of  the  expen  system.  For  example,  the 
seismologist  can  list  each  rule  that  has  been  invalidated  more  than  x%  of  the  times  it  was  used. 
He  can  then  identify  all  events  that  used  this  rule  as  part  of  the  decision  process,  plot  the  event 
locations  on  a  map  to  see  the  spatial  distribution  of  events  for  which  the  rule  was  valid  and 
invalid,  retrieve  the  original  data  for  selected  examples,  review  the  explanation,  etc. 

The  KAS  objective  is  to  focus  attention  on  deficient  elements  of  the  knowledge  base  and  to 
facilitate  a  systematic  review  of  relevant  events  to  understand  these  deficiencies.  Automated 
acquisition  of  knowledge  (machine  learning)  from  this  information  is  not  attempted.  Instead, 
the  concept  is  to  provide  the  information  in  a  convenient  form  to  a  highly-trained  seismologist 
who  will  use  his  judgement  to  construct  new  knowledge  to  be  added  to  the  system.  Since 
accumulation  of  adequate  experience  takes  time,  we  anticipate  that  the  knowledge  base  will  be 
changed  infrequently  (perhaps  once  a  quarter). 

The  remaining  functions  of  the  KAS  are  knowledge-base  augmentation  and  knowledge-base 
validation.  The  first  requires  editing  tools  to  change  the  knowledge  ba.se,  and  the  second 
requires  tools  to  verify  that  the  nev,  knowledge  is  consistent  and  results  in  improved  system 
performance.  In  IAS  the  augmentation  of  the  rules  is  done  by  editing  the  Lisp  code  expressing 
them.  There  is  a  separate  script  acquisition  system  which  is  u.sed  to  construct  new  scripts  (see 
Section  4.4).  The  concept  for  knowledge-base  validation  is  to  carry'  out  regression  tests  using 
previously  processed  events.  The  "audit  records"  play  an  essential  role  in  the  selection  of  the 
events  to  be  used  for  the  regression  testing  since  they  include  a  record  of  each  use  of  a 
particular  element  of  the  knowledge  base. 

In  summary,  when  viewed  from  a  "knowledge-based  sy.stem"  perspective,  the  important 
features  of  IAS  are; 

•  The  requirement  for  unattended  automatic  interpretation  of  incoming  data. 

•  The  availability  of  a  human  expert  capable  of  validating  the  solutions  obtained  from  the 
automated  sy.stem. 

•  The  requirement  for  caching  a  record  of  the  decision  process  for  retrieval  long  after  the 
automatic  .solution  is  completed. 

•  A  complex  problem  domain  that  makes  automatic  knowledge  acquisition  (machine 
learning)  so  difficult  as  to  be  impractical  for  now. 

The  decision  process  and  knowledge  base  have  been  .structured  to  allow  caching  of  the  needed 
information  wiiliin  the  confines  uf  a  relational  database.  This  requires  tradeoffs,  but  it  does  not 
appear  to  have  imposed  any  significant  limitations  on  the  architecture  of  the  expert  system  for 
the  automated  processing. 
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2J.  MS  ARCHITECTURE 

A  high-level  sketch  of  the  MS  architecture  was  presented  in  Figure  1.3  and  described  in 
Section  1.3.  In  Figure  2.5  and  this  section  we  expand  the  description  of  the  architecture  to  the 
next  level  of  detail.  As  shown  in  the  figure,  the  real-time  NORESS  data  are  transmitted  via 
land-line  to  the  NORSAR  Data  Analysis  Center  (NDAC).  The  real-time  ARCESS  data  are 
transmitted  in  a  similar  way  via  satellite  link.  As  the  data  are  acquired,  quality  control  and 
state-of-hcalth  checks  are  applied.  The  full  data  stream  from  each  array  is  stored  on  a  "disk 
loop"  which  is  a  first-in,  first-out  data  buffer  which  contains  the  most  recent  84  hours  of 
seismic  data.  At  the  same  tine,  all  data  are  archived  on  tape  in  the  continuous  data  archive 
shown  in  uic  figure.  All  these  elcinerus  are  external  to  the  IAS  system  which  begins  by 
retrieving  data  from  the  "disk  loops"  for  each  array. 

The  IAS  include'-  the  software  to  retrieve  the  data  from  the  disk  loops,  the  signal  processing 
shown  in  Figure  2.5,  and  the  elements  connected  to  NORSAR  by  the  "Unix  Wide-Area 
Network  Connection."  TThus,  the  IAS  includes  computers  and  software  on  three  Local-Area 
Networks"  connected  by  the  "Unix  WAN."  The  two  LANs  on  the  right  arc  the  Automatic  and 
Interactive  Analysis  modules  described  in  Sections  2.2-2.4  ai.i  the  Central  Data  Repository 
(CDR).  The  results  obtained  by  the  IAS  analysis  (event  interpretations  and  waveform 
segments)  eventually  migrate  to  the  CDR  for  long-term  storage  and  retrieval  by  other  users  of 
the  data.  The  latter  two  WANs  arc  colocated  at  the  Center  for  Seismic  Studies,  '.vhile  the 
NDAC  connecdon  requires  a  satellite  link.  Using  computers  anywhere  on  this  WAN  is  little 
different  from  sitting  at  the  computer  console,  though  the  limited  bandwidth  (56kbps)  and 
travel-time  delay  (about  0.5  sec  to  echo)  make  it  inconvenient  to  do  some  kinds  of  work  over 
the  satellite  link. 

The  processing  is  distributed  to  keep  the  data-intensive  signal  processing  near  the  real-time 
data  acquisiuon  ai  NDAC  because  only  a  portion  of  the  data  (10-20%)  include  signals  of 
interest.  As  snown  in  Figure  2.5,  the  fdll-period  data  remain  at  the  NDAC,  and  only  "event 
segments”  are  transmitted  to  the  Center  for  Seismic  Studies  for  eventual  archiving  in  the  CDR. 
These  "event  segments"  arc  requested  automatically  by  the  "expen  system"  using  simple  rules 
for  the  selection  of  segments.  These  rules  consider  'he  type  of  event  (local,  regional  or 
tcleseismic),  and  the  duration  needed  to  include  a'l  the  signal  energy  and  an  appropriate  pre- 
event  noise  sample.  The  panicular  rules  (sec  Section  4.3)  are  easy  to  change  with  experience 
and  changing  requirements. 

The  "event  segments"  are  queued  for  the  interactive  analyst  review  discussed  in  Sections  2.2- 
2.4.  If  the  "expert  system"  makes  an  error,  the  analyst  can  request  additional  data  which  are 
available  immediately  if  the  request  is  made  while  the  data  are  still  residci.,  on  the  84-hour 
"di.sk  loop." 
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Fiffure  2  5  The  overall  arehiicclure  of  IAS. 


Ill  SOFTWARE  ARCHITECTURE 


The  overall  concept  for  the  system  was  described  in  general  terms  in  Section  II.  In  this  section 
we  describe  how  this  concept  is  translated  into  software.  In  particular,  we  describe  the  overall 
architecture  in  terms  of  the  individual  processes  and  their  interaction.  In  Section  IV  we 
describe  in  some  detail  how  the  functions  arc  accomplished  within  each  of  the  major  modules. 
In  Section  V  we  discuss  the  mapping  of  these  software  modules  to  computer  hardware. 

3.1.  IAS  SOFTWARE  ARCHITECTURE 

A  high-level  view  of  the  software  architecture  is  provided  in  Figure  3.1.  The  system  includes 
43  processes  plus  the  relational  DBMS.  Thirty-seven  of  these  processes  are  shown  in  Figure 
3.1  grouped  into  classes  with  closely  related  functionality.  The  other  6  processes  provide 
control  and  administrative  functions,  and  no  attempt  is  made  to  display  them  graphically  here. 

In  subsequent  sections  we  will  describe  each  of  the  processes  included  in  the  IAS  system.  From 
a  seismological  perspective  the  major  processes  are  SigPro,  ASSESS,  Eventid,  ScripiMatch, 
MERSY,  Sratio,  ARS,  SAS,  PerfV.  and  iastalk.  In  Section  IV  we  will  describe  how  each  of 
these  major  processes  performs  its  functions. 

The  "arrays"  and  "Disk  Loop"  shown  in  Figure  3.1  are  external  to  the  IAS  system.  The  "Disk 
Loop"  is  a  first-in,  first-out  data  buffer  developed  by  Science  Horizons,  Inc.  (SHI)  and 
NORSAR.  Each  "Disk  Loop"  (one  for  each  array)  is  configured  to  store  70  hours  of  data. 
SHI  also  provided  the  {hub_cb2db)  program  which  became  the  hub_cb2bg2z  process 
(described  in  the  next  section)  after  minor  modification. 

In  the  following  sections  we  describe  groups  of  related  processes.  The  grouping  is  that  shown 
in  Figure  3.1,  plus  two  additional  groups  not  shown  in  the  figure.  With  the  exception  of  the 
first  of  these  sections  which  describes  the  DBMS,  all  of  these  sections  have  the  same  form. 
Each  begins  with  a  brief  description  of  the  overall  function  of  the  processes  in  that  group,  and 
this  is  followed  by  a  description  of  these  processes  in  the  following  format; 

Function  The  major  functions  perfonned  by  the  process  are  described. 

Language  The  language  or  languages  (Fortran.  C,  Lisp,  SQL)  used  in  this  process  are 
described. 

Input  The  input  to  the  process  is  described  from  a  functional  perspective. 

Output  The  output  to  the  process  is  described  at  the  same  level  of  detail  as  the  input. 

IPC  Processes  communicating  with  this  process  via  "Inter-Process  Communication" 

messages  (see  Section  3.13)  are  identified,  and  the  general  content  of  the  messages 
is  described. 

Parents  Processes  that  spawn  this  process  are  identified. 

Children  Processes  spawned  by  this  process  arc  identified. 
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Figure  3.1.  The  software  architecture  of  IAS  is  shown  in  terms  of  the  major  functional 
elements  of  the  system.  The  processes  within  each  of  these  functional  elements  are  identified. 
The  arrows  indicate  the  flow  of  the  most  important  data.  The  key  messages  exchanged  during 
the  automated  processing  are  also  shown. 


32.  NDAC  DBMS  AND  CENTER  DBMS 

All  parametric  data  generated  by  IAS  are  managed  by  a  commercial  relational  database 
management  system  (RDBMS),  and  the  processes  retrieve  and  store  data  via  SQL  embedded  in 
the  source  code.  The  initial  implementation  of  the  system  used  Ingres  throughout.  In 
November,  1989,  the  "NDAC  DBMS"  (Figure  3.1)  was  changed  to  Oracle.  The  database 
schema  is  an  extension  of  the  "Center  for  Seismic  Studies  Database  Structure  Version  2.8" 
(Brennan,  1987)  with  added  attributes  and  tables  required  to  manage  new  data  objects 
introduced  during  the  IAS  development  (see  Appendix  A).  The  concept  motivating  this  DBMS 
schema  is  outlined  in  this  section.  Most  of  the  new  data  objects  were  introduced  to  manage 
data  generated  by  the  expert  system.  There  are  also  several  new  tables  which  provide  process 
state  information  for  fault  recovery. 

The  database  includes  large  data  objects  that  are  not  stored  in  the  RDBMS,  but  in  the  Unix  file 
system.  These  are  the  time  series  data  (stored  in  h)  the  spectra  (stored  in  fs)  and  the  f-k 
power  spectra  (stored  in  fk).  Tables  in  the  RDEMS  (wfdisc,  fsdisc,  fkdisc)  manage  the  pointers 
to  these  Unix  files. 

As  shown  in  Figure  3.1,  IAS  includes  independent  DBMS’s  at  NDAC  and  the  Center.  Data 
are  transferred  between  the  two  using  UUCP  (see  Sections  3.5  and  3.6).  Independent  counters 
are  used  at  the  two  sites  to  provide  the  unique  indexes.  The  files  (w,  etc.)  are  transferred  in  an 
analogous  way,  with  independent  wfdisc,  etc.,  tables  maintained  in  the  two  DBMS. 

An  abstract  view  of  the  IAS  DBMS  schema  is  presented  in  Figure  3.2.  The  major  tables  are 
the  detection,  detloc,  loc  triad  that  describe  events,  and  the  audit  table  that  stores  a  history  of 
the  decision  process.  Each  detected  signal  is  represented  by  a  tuple  in  the  detection  table,  and 
each  event  is  represented  by  one  or  more  tuples  in  loc.  The  detloc  table  links  events  to 
detected  signals  associated  with  them.  The  many-to-one  linkages  from  detloc  indicate  that 
many  detections  are  associated  with  one  event,  and  that  a  single  detection  may  be  associated 
with  several  (hypothesized)  event  solutions.  This  separation  of  detections  from  events  with  a 
linkage  between  them  is  a  powerful  concept  introduced  in  the  original  Center  DBMS  (Berger 
et  ai,  1984)  where  it  appears  in  the  arrival,  assoc,  origin  triad.  The  triad  in  Figure  3.2  are 
these  same  tables  adapted  to  the  IAS  regional  array  problem.  As  shown  in  the  figure,  many 
tables  can  be  added  (with  one-to-one  linkages)  as  the  need  arises  to  describe  the  signals  and 
events. 

New  features  introduced  in  the  IAS  RDBMS  include  the  audit  relations  and  the  heirarchical 
linkage  within  the  detloc  and  loc  tables  (represented  by  "ancestors"  and  "children").  In  detloc 
this  is  used  to  link  sevc:al  interpretations  of  a  particular  detection  (e.g.,  the  automated 
processing  identifies  it  as  Sn,  but  the  analyst  changes  it  to  Lg).  In  loc  this  is  used  to  link  an 
evolving  scries  of  hypotheses  for  the  solution  for  a  particular  event. 

The  audit  data  are  described  in  some  detail  in  Sections  4.3.4  and  4.7.1.  As  indicated  in  the 
figure,  many  audit  records  are  written  (by  ASSESS)  to  explain  the  reasoning  for  each 
association  between  a  detected  signal  and  an  event  solution.  There  arc  one-to-one  linkages  to 
tables  that  elaborate  this  reasoning,  and  many-to-one  linkages  to  tables  specifying  the  rules. 
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organizalion  of  Ihc  tables  in  the  IAS  relational  DBMS. 


3-3.  WAVEFORM  AGENT 


The  basic  function  of  these  processes  is  to  extract  data  from  the  "Disk  Loop"  for  the 
elements  of  the  system  that  need  them.  The  SPServer  process  included  in  this  element  is 
intelligent  process  which  controls  much  of  the  automated  processing  at  the  NDAC.  The  two 
processes  included  in  the  Waveform  Agent  are  described  below. 


* * *  *h  ub_cb2dbg2z * * * * 

rur.ction  This  process  extracts  a  specified  segment  of  data  from  the  circular  buffer  and 
converts  it  to  the  IAS  external  file  format  (.wfdisc  and  .w)  and  inserts  the  .w  files 
into  the  local  file  system. 

Language  C. 

Input  The  start-time,  end-time  and  channel  identifiers  for  the  data  segment  requested. 
Output  The  .wfdisc  and  .w  formatted  version  of  the  requested  data. 

IPC  None. 


Parents  SPServer,  sendjwaves 
Children  None 


****SPServer**** 


Function 


Language 

Input 

Output 

IPC 

Parents 

Children 


This  is  an  intelligent  data  server  for  SigPro.  SPServer  receives  requests  for  new 
data  from  SigPro.  frees  disk  space  if  necessary,  then  runs  hub_cb2dbg2z  to  get  the 
time  series  data.  The  length  of  the  data  segment  retrieved  depends  upon  the 
processing  stams  of  SigProt-  SPServer  also  inserts  the  wfdisc  information  into  the 
local  DBMS. 

C. 

The  .wfdisc  file  created  by  hub_cb2dbg2z. 

The  .wfdisc  inserted  into  the  local  DBMS. 

Processing  is  initiated  with  a  data  request  from  SigPro.  It  sends  a  message  to 
SigPro  when  new  data  are  available  for  processing. 

startSigPro 

hub_cb2dbg2z 


t  When  SigPro  is  running  faster  than  real-time,  data  are  retrieved  in  30  minute  segments.  The  max¬ 
imum  segment  extracted  (when  SigPro  is  behind  real-time)  is  2  hours.  The  segment  length  varies 
between  these  limits  depending  on  the  current  situation. 
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3.4.  SIGNAL  PROCESSING 

The  overall  function  was  described  in  Sections  2.2  and  2.3,  and  more  detail  will  be  provided  in 
Section  4.2.  Two  processes  are  included. 


****SigPro**** 

Function  The  signal  processing  described  in  Section  4.2  is  done  in  this  module.  Knowledge 
of  the  last  time  processed  is  maintained  in  the  DBMS,  and  this  is  used  to  request 
new  data  upon  initiation  by  startSigPro.  In  continuing  operation  SigPro  is 
controlled  via  conversational  communication  with  SPServer. 


Language 

Input 


Output 


IPC 


Parents 

Children 


Fortran  with  embedded  SQL  and  some  C  subroutines  for  waveform  data  access. 

Time  series  for  the  all  short-period  channels  (25  vertical  and  8  horizontal  channels 
at  40  samples/sec  for  NORESS  and  ARCESS)  are  retrieved  from  the  local  file 
system.  In  addition  to  .wfdisc,  SigPro  also  uses  quasi-station  tables  from  the 
DBMS  for  site  geometry  and  beam  and  filter  indexing.  From  external  files,  SigPro 
accesses  beam  recipes  and  filter  coefficients. 

The  "features"  are  written  to  the  local  DBMS  and  file  system.  These  include 
parameters  describing  signal  detections  and  their  character  (see  Section  4.2) 
inserted  into  the  appropriate  tables  (primarily  detection)  in  the  DBMS,  and  files 
with  the  Fourier  and  f-k.  spectra  for  each  detection. 

SigPro  sends  a  message  to  SPServer  when  it  completes  its  processing  of  a  data 
segment.  SigPro  receives  a  message  from  SPServer  when  more  data  are  available 
for  processing. 

StartSigPro 

None. 


****startSigPro**** 

Function 

This  script  starts  all  the  processes  needed  for  signal  processing  in  Norway, 
provided  as  a  convenience  for  the  administrator  of  the  system. 

Language 

Bourne  shell. 

Input 

None. 

Output 

None. 

ipn 

None. 

Parents 

None. 

Children 

Dispatcher,  SigPro,  SPServer,  d_test. 

It  is 
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3J.  SEND  AGENT 


The  basic  function  of  the  processes  in  this  group  is  to  u-ansfer  data  from  the  NDAC  to  the 
Center.  TTie  UUCP  protocol  is  used  for  the  transfer,  so  these  processes  reformat  the  data  for 
transmission  via  this  method.  The  transmitted  data  fall  into  two  categories  which  are  handled 
differently.  The  data  created  by  SigPro  are  transmitted  on  a  regular  schedule  (e.g.,  hourly). 
Segments  of  unprocessed  time-series  data  are  transmitted  upon  request  from  the  Display 
Agent,  with  the  request  based  on  mterpretation  of  the  data  by  the  Locate  &  Identify  group  of 
processes.  There  are  three  processes  in  this  group. 


****send_det**** 


Function 


Language 

Input 

Output 

/PC 


This  process  extracts  data  describing  all  detections  written  to  the  local  database 
since  the  last  transmission,  packages  these  data  for  transmission,  and  transmits 
them  to  the  Center  via  uux.  The  data  include  parameters  from  the  DBMS 
(primarily  in  detection)  and  files  (spectra  and  f-k). 

C  and  SQL. 

The  SigPro-time  table  from  the  DBMS 

The  input  data  repackaged  for  transmission  via  uux. 

None. 


Parents  send_detections 
Children  None. 


****send_detections**** 


Function 

Language 

Input 

Output 

IPC 

Parents 

Children 


This  script  provides  run-time  parameters  for  sendjdet. 
schedule  (e.g.,  once  per  hour). 

Bourne  shell. 

None. 

None. 

None. 

Spawned  on  a  prescribed  schedule  by  cron. 
send_det 


It  is  initiated  on  a  regular 


****send 


Function 


Language 

Input 

Output 

IPC 

Parents 

Children 


waves**** 

This  script  accepts  requests  for  specified  segments  of  time-series  data,  retrieves  the 
requested  data  via  the  hub_cb2dbg2z  process,  and  sends  them  to  the  requested 
address  via  uux. 

Bourne  shell. 

A  description  of  the  requested  data  in  terms  of  station  (array)  name,  start-time,  and 
end-time. 

Time-series  data  formatted  for  transmission  via  uux. 

None. 

Spawned  by  request_waves  via  uux. 
hub_cb2dbg2z 
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3.6.  RECEIVE  AGENT 

The  function  of  the  processes  in  this  group  is  to  receive  the  data  transmitted  via  UUCP  by  the 
Send  Agent  group  of  processes  and  to  insert  them  in  the  local  file  structure  and  DBMS.  The 
data  extracted  from  the  NDAC  DBMS  are  written  to  the  corresponding  tables  in  the  local 
DBMS,  and  the  data  objects  managed  by  the  file  system  are  written  to  the  appropriate  parts  of 
ihe  local  Hie  system. 

♦  ★  ^  ^receive  ^ 

Function  This  process  receives  the  detection  data  transmitted  via  uux  by  send_det,  unpacks 
them,  and  inserts  them  into  the  local  DBMS  and  file  system. 

Language  C. 

Input  The  detection  data  formatted  for  transmission  via  uux. 

Output  The  detection  data  inserted  into  the  local  DBMS  and  file  system. 

IPC  Message  to  Agent  informing  it  of  newly  arrived  data. 

Parents  receive_detections 

Children  None. 

*  *  *  *recei  ve_detections*  *  *  * 

Function  This  script  provides  run-time  parameters  for  receive_det. 

Language  Bourne  .shell. 

Input  None. 

Output  None. 

IPC  None. 

Parents  Spawned  by  a  uux  process  spawned  by  sendjdet. 

Children  receive_det 

4*  j  ^ 

Function  This  process  inserts  the  wfdisc  tuples  transmitted  by  send_waves  into  the  local 
DBMS. 

Language  C, 

Input  Wfdisc  tuples  formatted  for  transmission  via  uux. 

Output  Wfdisc  tuples  inserted  into  the  local  DBMS. 

IPC  Message  to  DA  informing  it  that  new  data  arc  available  for  display. 

Parents  receive_waves 
Children  None. 
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*  *  *  *  recei  ve_wa  ves  *  *  *  * 


Function  This  script  receives  the  time-series  transmitted  by  send_waves,  formats  them  into 
the  proper  format  (.w),  and  inserts  these  files  into  the  local  directory  structure. 
Language  Bourne  shell. 

Input  Data  packaged  by  send_waves. 

Output  Files  formatted  according  to  IAS  format. 

IPC  None. 

Parents  Spawned  by  a  uux  process  spawned  by  sendjwav. 

Children  receivejwav 

3.7.  LOCATE  AND  IDENTIFY 

The  processes  in  this  group  retrieve  the  features  describing  the  detections  from  the  local 
DBMS  and  file  system  and  operate  on  these  data  to  associate  detections  with  events  and  then 
locate  these  events.  Those  detections  that  are  associated  with  seismic  events  are  processed  to 
isolate  features  that  identify  their  source  as  natural  or  man-made  seismic  events  of  specified 
type.  The  major  process  in  this  group  is  ASSESS,  the  expert  system  which  associates  the 
detections  and  locates  events.  Subsequent  processes  operate  on  those  groups  of  detections 
associated  with  events  by  ASSESS. 

Function  This  process  specifies  the  detections  to  be  processed  by  ASSESS.  It  is  initiated  by 
a  message  from  receive jdet  indicating  that  new  detections  arc  available,  or  by  an 
operator  command. 

Language  C.  with  SQL 

Input  The  time  window  including  the  detections  to  be  processed. 

Output  None. 

IPC  Messages  from  receivejdet  indicating  that  detections  are  available;  messages  to 

ASSESS  identifying  the  detections  to  process. 

Parents  Manager. 

Children  None. 

****startASSESS**** 

Function  This  script  conveniently  starts  ASSESS. 

Language  Bourne  shell. 

Input  None. 

Output  None 

IPC  None 

Parents  Manager. 

Children  ASSESS. 
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****ASSESS**** 

Function  This  process  is  the  expert  system  that  associates  detections  with  seismic  events. 

Language  Lisp  and  some  Fortran  and  C  subroutines  with  embedded  SQL. 

Input  "Features"  describing  detections  extracted  from  the  appropriate  tables  in  the 
DBMS. 

Output  "Results"  including  the  associated  detections,  the  event  locations  and  an  an  audit 
trail  describing  the  reasoning.  The  major  DBMS  tables  include  .loc,  .detloc,  and 
.audit. 

I  PC  Messages  from  AAgenr,  messages  to  DA. 

Parents  startASSESS. 

Children  None. 

****EventId**** 

Function  This  process  controls  several  proces.ses  that  compute  data  used  for  event 
identification  and  integrates  the  results  to  provide  an  identification. 

Language  C. 

Input  None 

Output  Event  identification  "Results"  to  the  eventid  table  in  the  DBMS. 

IPC  Messages  from  ASSESS.  Messages  to  event  idcntificadon  processes;  ScriptMatch, 

MERSY,  Sratio. 

Parents  Manager. 

Children  None. 

****ScriptMatch**** 

Function  This  process  attempts  to  match  the  "Features"  of  a  group  of  detections  associated 
with  an  event  to  the  pattern  (a  "script")  of  detections  from  selected  sets  of  previous 
events.  A  close  match  indicates  that  the  event  is  similar  to  the  events  used  to 
make  the  "script." 

Language  Lisp 

Input  "Features"  and  "Results"  arc  retrieved  from  the  appropriate  tables  in  the  DBMS. 
Scripts  are  computed  by  SAS  and  arc  stored  in  special  files. 

Output  The  results  of  the  script-match  are  written  to  the  DBMS. 

IPC  Messages  from  Eventid. 

Parents  Manager. 

Children  None 
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****MERSY**** 

Function  The  Multiple  Event  Recognition  System  analyzes  the  spectra  of  the  detections  as¬ 
sociated  with  an  event  to  seek  evidence  that  the  event  is  made  up  of  several  explo¬ 
sions  closely  spaced  in  time.  Such  events  arc  common  in  many  typ)es  of  mining, 
and  strong  evidence  of  this  "ripple-firing"  provides  high  confidence  that  the  event 
is  an  industrial  explosion.  Particular  patterns  can  sometimes  be  used  to  identify 
events  in  a  specific  mine. 

Language  C.  Fortran  and  SQL 

Input  "Features"  and  spectra  from  the  DBMS  and  filesystem. 

Output  Results  of  the  analysis  are  wrinen  to  the  DBMS  and  filesystem. 

IPC  Messages  from  Eventid. 

Parents  Manager. 

Children  None. 

****Sratio**** 

Function  The  Sralio  process  analyzes  the  spectra  of  Pn  and  Lg  detections  associated  with  an 
event  to  obtain  an  estimate  of  the  ratio  of  S-wave  radiation  to  P-wavc  radiation.  A 
high  ratio  is  consistent  with  an  earthquake;  a  low  ratio  is  inconclusive. 

Language  Fortran. 

Input  "Features"  and  "Results"  are  retrieved  from  the  appropriate  tables  in  the  DBMS, 
and  the  spectra  are  retrieved  from  the  file  system. 

Output  Results  of  the  analysis  are  written  to  the  DBMS. 

IPC  Messages  from  Eventid. 

Parents  Manager. 

Children  None. 

****NetMag**** 

Function  A  request  for  a  magnitude  is  sent  to  this  process  which  then  directs  the 
computation  of  the  requested  network  magnitude  by  initiating  the  individual  station 
magnitude  calculations.  In  las  all  station  magnitudes  are  computed  by  MaLg. 

Language  C. 

Input  None. 

Output  None 

IPC  Messages  specifying  the  event  for  which  the  magnitude  is  to  be  computed  are 

received  from  the  requesting  process  (e.g.,  DBS,  DA)  and  messages  requesting  a 
station  magnitude  are  sent  to  MaLg. 

Parents  None. 

Children  None. 
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4c 

function  This  process  estimates  the  magnitude  for  a  specified  event  from  the  amplitude  of 
Lg.  A  recipe  file  specifies  the  channels  (beams  or  single  elem  nts),  time  window, 
filter,  and  distance  correction  for  the  comput^Mon. 

Lanuage  Fortran. 

Input  The  event  location  and  quasi-static  files  providing  the  needed  parameters  (c.g.,  in¬ 
strument  corrections,  recipe  files)  are  obtained  from  the  DBMS.  Unprocessed  or 
beamed  waveforms  (depending  on  the  recipe)  are  obtained  from  the  database. 

Output  The  comput''d  magnitudes  arc  written  to  the  DBMS  station  magnitudes  to  .mag, 
and  an  updated  avecrage  network  magnitude  to  .loc. 

IPC  Messages  from  NetMag 

Parents  None. 

Children  None. 

3.8.  FORM  BEAMS 

This  process  calculates  beams  for  specified  time  segments  and  beam  parameters  retrieved  from 
a  beam  recipe  file.  In  routine  (realtime)  processing,  several  standard  beams  arc  calculated  for 
each  event.  The  beam  recipe  for  these  standard  beams  includes  a  coherent  high-frequency  (4-8 
Hz)  beam  steered  toward  the  event  at  an  apparent  velocity  of  8.1  km/s,  an  infinite  velocity 
low-frequency  (1-4  Hz)  incoherent  beam,  and  an  infinite  velocity  incoherent  horizontal  b  jn  at 
(1-4  Hz).  These  beams  were  designed  to  emphasize  Pn,  Lg,  and  Sn,  respectively. 

Function  This  process  calculates  a  set  of  beams  for  a  specified  array  elements,  time  window, 
azimuth,  filter. 

Language  Fortran  with  some  C  subroutines  for  acquiring  waveform  data. 

Input  Raw  waveforms  (.w  files)  from  the  iilcsy.stcm  and  the  beam  recipe  specifying  the 
beams  to  be  calculated. 

Output  Beamed  waveform  data  (.w)  arc  written  to  the  filesystem  and  the  .wfdisc  table  is 
updated. 

IPC  Message  from  the  DA  specitying  the  event  and  time  segment  for  which  beams  arc 

to  be  calculated. 

Parents  Manager 
Children  None. 
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3.9.  DISPLAY  4GENT 


The  processes  in  this  group  retrieve  from  the  NDAC  the  original  time  series  for  segments 

including  the  expected  arrival  lime  of  detections  from  located  events.  They  also  initiate  the 

display  of  the  event  solutions. 

****jy^>i.*** 

Function  The  DA  coordinates  the  various  activities  that  are  required  once  a  solution  has 
been  formed,  namely  sending  out  the  request  for  waveform  segments,  waiting  for 
the  arrival  of  the  waveforms,  initialing  the  beamforming  and  waiting  for  the 
completion  of  the  beams,  and  plotting  the  results. 

Language  C. 

Input  The  DA  uses  location  solutions  and  travel-time  tables  to  determine  which 
waveform  segments  to  request.  For  regional  events,  the  selected  segments  begin 
30  seconds  before  the  expected  Pn  arrival  time  and  have  a  7  minute  duration. 

Output  The  DA  has  no  output  of  its  own;  its  products  result  fror  child  processes. 
However,  the  DA  d^ics  have  an  X  status  display. 

IPC  ASSESS  informs  the  DA  of  new  solutions.  receive_wav  informs  the  DA  when 

requested  waveform  segments  have  arrived.  The  DA  starts  bcamfotming  by 
sending  a  message  to  Beamcr;  Beamer  responds  when  bcamforming  is  complete. 
Finally,  plotting  of  solutions  is  staned  by  sending  messages  tt  EvPlot  and  Review. 

Parents  Manager 

Children  requestjwaves 

****request_waves**** 

Function  requestjwaves  is  a  shell  script  for  submitting  rcquesg>  for  waveform  segments 
from  Norway  The  script  takes  a  station  name  and  stan  an^  end  times  for  the 
requested  segment  as  parameters,  then  initiates  a  send_waves  remotely  in  Norway 
via  uux. 

Language  C  shell. 

Input  The  station  name  and  stan  and  end  times  of  the  mquested  Sv^gment. 

Output  None. 

IPC  None. 

Parents  Display  Agent 

Children  sendjwaves  is  spawned  remotely  via  uux 
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3.10.  DISPLAY 


This  group  of  processes  displays  the  results  of  IAS  processing  using  X  graphics  on  raster 
display  devices  and  hardcopy  on  PostScript  printers.  The  displays  include  text  and  graphics. 
The  text  displays  include  lists  of  detections  with  selected  features  and  a  seismic  bulletin  with 
locations  and  associated  detections.  The  graphical  displays  include  appropriately  annotated 
waveform  and  map  displays.  Some  processes  display  results  automatically  as  they  are  created, 
others  are  initiated  by  an  operator. 

4c  ^  y  p  I Q  ^  4c  *  4c  * 

Function  This  process  formats  a  display  of  each  event  located  by  ASSESS.  The  display 
includes  a  map  showing  the  event  location  and  error  ellipse  with  the  associated 
detections  (plotted  as  rays  at  the  estimated  azimuth).  There  are  three  standard 
beams  for  each  array  from  Beamer  All  detections  on  each  beam  segment  are 
marked  as  are  the  theoretical  arrival  times  (for  the  estimated  location)  for  major 
seismic  phases.  This  process  al.so  lists  selected  features  for  each  detection 
displayed. 

iMnguage  C  with  SQL 

Input  "Features"  and  "Results"  tre  retrieved  from  the  appropriate  tables  in  the  DBMS, 
and  the  standard  beams  are  retrieved  from  the  appropriate  .w  files. 

Output  A  metafile  description  of  the  display. 

IPC  Message  from  the  DA  to  plot  a  designated  solution. 

Parents  Manager. 

Children  EvPrint. 

****EvPrint**** 

Function  The  display  formatted  by  EvPlot  is  plotted  on  a  PostScript  printer  (hard  copy)  by 
this  process. 

Language  C. 

Input  The  metafile  from  EvPlot. 

Output  Hardcopy  output, 

IPC  None. 

Parents  EvPlot. 

Children  None. 
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****Revie\v**** 


Function 


Language 

Input 

Output 

/PC 


This  process  provides  displays  that  are  similar  in  format  to  those  provided  by 
EvPlot.  However,  the  Review  displays  are  done  in  X  on  a  workstation.  Also, 
Review  does  not  use  the  embedded  program  tiiat  ploLS  coastline  maps  for  EvPlot, 
but  sends  messages  to  the  X  displays  produced  by  Map. 

C  with  SQL. 

"Features"  and  "Results"  arc  retrieved  from  the  appropriate  tables  in  the  DBMS, 
and  the  standard  beams  arc  retrieved  from  the  appropriate  .w  files. 

An  X  display  showing  waveforms  and  a  table  of  detections  associated  with  the 
specified  solution. 

Message  from  DA  to  plot  a  designated  solution;  message  to  Map  to  plot  locations 
and  detections. 


Parents  Manager. 
Children  None. 


*  *  *  ★  U  U  ★  5*c 


Function 


Language 

Input 

Output 

IPC 

Parents 

Children 


This  process  is  used  for  demonstration.  Its  displays  arc  nearly  identical  to  those 
produced  by  Review.  The  only  difference  is  that  the  waveform  displays  in  Run 
scroll  at  a  user-selected  rate.  Also,  selection  of  the  events  to  be  displayed  in  Run 
is  in  terms  of  a  time  window  rather  than  by  an  event  identifier. 

C  with  SQL. 

"Features"  and  "Results"  are  retrieved  from  the  appropriate  tables  in  the  DBMS, 
and  the  standard  beams  arc  retrieved  from  the  appropriate  .w  files. 

An  X  display. 

Message  from  operator  specifying  time  period  to  display;  message  to  Map. 
Manager. 

None. 


4c 


Function 

Language 

Input 

Output 

IPC 

Parents 

Children 


This  process  provides  a  bulletin  summarizing  the  results  obtained  by  IAS. 
C  with  SQL. 

"Features"  and  "Results"  from  the  appropriate  tables  in  the  DBMS. 

A  troff-formatted  file  to  be  printed  on  a  PostScript  printer. 

None. 

None. 

None. 
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3.11.  ANALYST  REVIEW 


These  processes  provide  the  capability  for  interactive  review  and  validation  of  solutions 

obtained  by  the  automatic  system.  Four  processes  are  included. 

****ARS**** 

Function  The  Analyst  Review  Station  is  an  interactive  process  providing  a  full  suite  of  tools 
to  review  and  correct  solutions  obtained  by  the  IAS  automated  processing. 

Language  C  with  embedded  SQL. 

Input  The  particular  event  to  be  analyzed  is  selected  by  the  analyst  or  via  an  IPC 
message.  The  results  of  the  automated  processing  are  retrieved  from  the 
appropriate  tables  in  the  DBMS  and  related  files.  Commands  controlling  the 
display  and  editing  functions  are  input  pointing  and  clicking  with  a  mouse. 

Output  Corrected  solutions  obtained  by  the  analyst  are  written  to  the  appropriate  tables  in 
the  DBMS.  A  link  is  maintained  between  the  solution  obtained  by  the  automatic 
processing  and  that  obtained  by  the  analyst. 

IPC  Messages  are  sent  to  Map  and  ivas  to  plot  locations  and  associated  detections. 

After  review  of  each  event  is  completed,  a  message  is  sent  to  PerfV  for 
performance  validation.  ARS  can  also  receive  messages  specifying  events  to  be 
displayed  for  analysis  from  Map  and  DBS. 

Parents  None. 

Children  None. 

Function  This  process  provides  a  variety  of  interactive  and  automatic  map  manipulation  and 
display  functions.  Numerous  color  maps  are  available  in  special  files  and  can  be 
selected  interactively  for  display.  These  maps  were  produced  from  digital 
elevation  and  feature  data  obtained  from  NOAA  and  DMA.  A  variety  of  overlays 
showing  cultural,  geographical,  political  and  seismological  information  can  be 
selected  interactively.  Seismic  locations  and  detections  obtained  by  the  automated 
processing  or  during  analyst  review  are  initiated  by  IPC  messages  which  can  be 
sent  by  automatic  or  interactive  processes. 

Language  C. 

Input  Bitmaps  and  overlays  are  read  from  files  which  are  located  by  information  in 
aesir _paths.  Interactive  selection  of  displays  is  via  pointing  and  clicking  a  mouse. 

Output  The  graphics  displays. 

IPC  Messages  describing  the  locations  and  detections  to  be  plotted  are  received  from 

ARS,  Run,  and  Review.  Pointing  and  clicking  on  events  plotted  on  the  map  sends 
to  ARS  the  information  necessary  to  retrieve  from  the  DBMS  all  available 
information  about  that  event. 

Parents  None. 

Children  None. 


SOFTWARE  ARCHITECTURE 


35 


****ivas**** 


Function 


Language 

Input 

Output 

IPC 


This  is  a  special-purpose  image  processing  and  display  system  from  International 
Imaging  Systems.  The  major  function  is  to  process  and  analyze  and  manipulate 
satellite  images,  but  it  :dso  displays  and  manipulates  the  digital  maps  displayed  by 
Map.  Many  of  the  overlays  available  for  Map  can  also  be  displayed  on  ivas.  In 
particular,  locations  and  detections  obtained  by  MS  can  be  displayed  on  the 
images. 

C. 

Maps  and  satellite  images  are  read  from  files.  User  control  is  mouse-driven. 
Processed  images  are  written  to  files  for  future  display. 

Messages  describing  the  locations  and  detections  to  be  plotted  are  received  from 
ARS,  Run,  and  Review.  Pointing  and  clicking  on  events  plotted  on  the  map  sends 
to  ARS  the  information  necessary  to  retrieve  from  the  DBMS  all  available 
information  about  that  event. 


Parents  None. 


Children  None. 


Function 

Language 

Input 

Output 

IPC 

Parents 


This  Database  Browser/Selector  is  an  interactive  process  that  is  used  to  select 
events  from  the  databa.se  for  input  to  other  processes. 

C  with  SQL. 

The  user  specifies  ranges  of  parameters  characterizing  the  locations  desired  DBS 
retrieves  from  the  DBMS  those  events  that  satisfy  the  input  constraints. 

Results  of  the  queries  to  the  DBMS  are  displayed  in  tabular  form.  Pointing  and 
clicking  particular  events  selects  them  for  transmission  to  another  process. 

Messages  identifying  selected  events  can  be  sent  to  any  application  connected  to 
the  Dispatcher  that  accepts  event  identifiers. 

None. 


Children  None. 
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3.12.  KNOWLEDGE  ACQUISITION 

The  knowledge-acquisition  processes  are  tasked  with  automating  the  correction,  refinement  and 
augmentation  of  the  ASSESS  knowledge-base.  This  is  accomplished  via  two  separate 
activities:  "performance  validation"  and  "performance  analysis."  Performance  validation 
compares  the  solutions  obtained  by  the  automated  processing  (ASSESS,  etc.)  with  the  solution 
validated  by  the  analyst  (ARS,  etc.).  Based  on  this  comparison  it  determines  which  elements  of 
the  automatic  reasoning  were  correct  and  incorrect  and  marks  the  appropriate  audit  tables  in  the 
DBMS.  Performance  analysis  refers  to  analysis  of  results  of  the  processing,  with  emphasis  on 
analysis  of  performance  validation  reflected  in  the  audit  records. 

****Pgj.JY 

Function  This  process  compares  the  automated  processing  results  with  analyst  results  and 
marks  the  audit  records  appropriately. 

Language  Lisp. 

Input  The  solutions  from  the  automatic  processing  and  analyst  validation  fprimarily  from 
the  detection,  detloc,  loc  tables  and  a  series  of  tables  with  audit  information). 

Output  Changes  to  the  relations  containing  audit  information. 

iPC  When  the  analyst  completes  review  of  an  event,  a  message  is  sent  to  PerfV 

including  a  pointer  to  the  tuples  describing  the  automated  solution  and  (when  the 
solution  is  changed)  the  analyst  solution. 

Parents  This  process  is  initiated  by  a  script  (startPerf/)  initiated  by  the  Manager  or  an 
operator. 

Children  None. 

****PerfV_message_agent**** 

Function  This  process  is  used  when  the  operator  prefers  to  defer  PerfV  processing.  It 
intercepts  the  PerfV  messages  and  caches  them  in  a  file. 

Language  C. 

Input  None. 

Output  A  file  containing  the  cached  PerfV  messages. 

IPC  The  messages  that  are  otherwise  received  by  PerfV. 

Parents  This  process  is  initiated  by  a  script  (startPerfVagent)  initiated  by  the  Manager  or 
an  operator. 

Children  None. 
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t<+**Perfv  message.sender**** 

Function  This  process  emulates  message  transmission  to  PerfV  from  ARS  using  the 
messages  cached  in  a  file  by  PerfV _message_agent. 

Language  C. 

input  A  pointer  to  the  file  created  by  Perf\'_message_agent. 

Output  None. 

iPC  Messages  to  PerfV. 

Parents  This  process  is  initiated  by  a  script  {startPerf' messages)  initiated  by  the  Manager 

or  an  operator. 

Children  None. 

****iastalk**** 

Function  This  process  provides  a  natural-language  interface  to  the  relations  containing  the 
results  of  the  processing  and  audit  trail.  The  primary  use  is  as  a  user-interface  for 
performance  analysis. 

Language  NLI  cormection  file. 

Input  Processing  results  are  obtained  from  the  DBMS  when  requested  by  queries  typed 
in  English  by  an  operator. 

Output  None. 

IPC  Messages  to  the  map  are  created  by  an  ephemeral  process  (swan_agent)  initiated 

by  a  command  to  plot  selected  events. 

Parents  None. 

Children  None. 

****SAS**** 

Function  SAS  (Script  Acquisition  System)  generates  scripts  from  selected  data  contained 
within  the  database  for  use  by  the  script  matcher  in  the  expert  system. 

Language  Lisp. 

Input  SAS  uses  an  set  of  origins  provided  by  the  user  and  queries  the  database  for  the 
seismic  parameters  associated  with  those  origins.  The  end  user  may  edit  any  of 
the  parameter  summaries  contained  within  the  script  created  by  SAS. 

Output  Scripts  are  saved  in  files  in  a  directory  specified  in  aesir_palhs. 

IPC  None. 

Parents  None. 

Children  None. 
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3.13.  DISTRIBUTED  PROCESSING  MANAGEMENT 

The  dislribuled-processing  management  processes  provide  inier-process  communication  (IPC) 

and  process  coordination  for  the  IAS  distributed  system.  The  Dispatcher  is  the  IPC  facility; 

the  Manager  is  the  process  coordinator.  Utilities  are  provided  for  handling  logical  pathnames 

and  testing. 

****Dispatcher**** 

Function  This  process  provides  IPC  communication  facilities  for  the  IAS  system.  Each  IAS 
process  connects  to  the  Dispatcher  which  then  routes  messages  between  processes. 

Language  C. 

Input  None. 

Output  None. 

IPC  Besides  handling  the  IPC  communications  for  all  the  IAS  processes,  the  Dispatcher 

accommodates  special  messages  for  initializing  service,  message  monitoring  and 
process  coordination. 

Parents  None. 

Children  None. 

♦♦♦^Manager**** 

Function  This  process  initializes/terminates,  monitors  and  coordinates  the  IAS  distributed 
system.  The  Manager  is  the  main  interface  to  IAS  for  the  system  administrator.  It 
includes  a  graphics  user-interface  for  process  and  message  traffic  monitoring  and 
for  system  configuration. 

Language  Lisp. 

Input  Initialization  files  describing  the  system  configuration. 

Output  Graphics  displays. 

IPC  The  Manager  uses  special  Dispatcher  messages  to  monitor  and  coordinate 

processing.  It  also  determines  the  recipient  of  messages  sent  to  a  process  class. 

Parents  None. 

Children  Many  IAS  processes  are  started  by  this  process. 

****aesir_paths**** 

Function  This  script  maps  logical  pathnames  into  physical  pathnames,  thus  localizing 

pathname  dependencies.  All  absolute  pathnames  in  the  I.^S  .sy.stem  should  be 
referenced  indirectly  through  this  script. 

Language  Bourne  shell. 

Input  Logical  pathname. 

Output  Physical  pathname. 

IPC  None. 

Parents  None. 

Children  None. 
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****d_test**** 

Function  This  process  is  a  generic  process  used  to  simulate  the  presence  of  any  MS  process 
for  testing.  d_test  connects  to  the  Dispatcher,  and  allows  the  user  to  send  and 
receive  messages  interactively. 

Language  C. 

Input  A  process  class  name. 

Output  None. 

IPC  Responds  to  messages  which  apply  to  the  process  class  being  imitated. 

Parents  None. 

Children  None. 

3.14.  MISCELLANEOUS  PROCESSES 

The  processes  in  this  group  are  ess«-ntially  utilities  or  administrative  tools. 

*  9|C  9k  HI  I  I Q  ^  % 

Function  This  process  is  used  to  manage  the  evolving  IAS  software.  It  creates  a  new 
directory  tree  which  is  a  replicate  of  the  current  directory  tree.  New  versions  of 
the  software  are  then  installed  in  this  new  directory  tree. 

Language  C. 

Input  None. 

Output  None. 

IPC  None. 

Parents  Called  by  an  administrator  of  the  system. 

Children  None. 

%  ^  *  %  * 

Function  This  process  computes  travel-time  tables  for  a  velocity  model  of  the  earth. 
Language  Fortran. 

Input  File  with  the  velocity  model;  user  specified  phase  id’s,  ranges  and  source  depths. 
Output  Files  with  travel-time  tables  for  each  specified  phase. 

IPC  None. 

Parents  None. 

Children  None. 
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3.15.  LINES  OF  CODE  IN  IAS 


The  size  and  complexity  of  the  code  in  these  43  processes  is  difficult  to  convey  in  a  simple 
way.  To  give  some  concept  for  the  scope  of  the  .software,  some  simple  numerical  measures 
are  summarized  in  the  table  below  The  code  is  divided  into  four  classes:  executable  source 
code  (in  Fonran,  C,  and  Lisp),  libraries  (in  C),  include  files  (containing  C  structure  definitions), 
and  shell  scripts.  This  count  includes  only  code  written  by  SAIC  and  its  subcontractors,  and 
the  complete  IAS  software  is  very  much  larger  (including  the  X  Window  System,  the  DBMS, 
NCAR  graphics,  the  natural-language  interlace  underlying  iastalk). 

In  each  of  the  three  classes  we  give  the  .size  (in  kilobytes,  KB),  the  number  of  files,  the  total 
lines  of  code,  the  number  of  lines  of  comments,  and  the  lines  of  executable  code.  These  are 
estimates,  considered  to  be  accurate  within  109).  The  difference  between  the  number  of  total 
lines  and  the  sum  of  comments  and  executable  code  is  primarily  makefile  lines. 

Among  the  interesting  features  of  the  data  in  the  table  is  that  about  one-third  of  the  system  is 
included  in  libraries  (primarily  for  database  access  and  graphics)  which  arc  shared  by  multiple 
processes.  This  is  an  indication  of  the  efficiency  of  the  implementation.  Also,  there  are  about 
2  lines  of  comments  for  each  3  lines  of  executable  code,  which  is  evidence  of  good  coding 
practice. 


Source 

Code 

Libraries 

Include 

Files 

Shell 

Scripts 

Total 

KB 

4, ()()() 

1 .6{)() 

300 

900 

Files 

829 

246 

179 

210 

1,464 

Total  Lines 

132, ()()() 

.sri.OOO 

10,000 

Comments 

.5 .5 ,()()() 

19.(X)() 

3,500 

Executable 

(1.3 ,()()() 

3.3  .{K)0 

6,000 

112,000 
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IV  FUNCTIONAL  DESCRIPTION 


4.1.  INTRODUCTION 

The  overall  architecture  of  the  IAS  was  described  in  Section  II  in  terms  of  the  basic  functions 
done  by  each  element  of  the  system.  In  this  section  we  look  in  more  detail  at  how  these 
functions  are  accomplished.  That  is,  we  describe  the  algorithms,  procedures  and  rules  applied 
to  the  data  during  the  processing.  The  subsections  are  listed  below  with  a  description  of  their 
relationship  to  the  elements  in  the  high-level  dataflow  (Figure  2.1)  and  software  architecture 
diagrams  (Figure  3.1). 

4.2  Signal  Processing 

This  functional  element  is  clearly  identified  in  Figure  2.1.  It  is  done  by  the  SigPro 
module  of  Figure  3.1. 

4.3  Expert  System  for  Location 

This  functional  element  is  clearly  identified  in  Figure  2.1.  It  is  done  by  the  ASSESS 
module  of  Figure  3.1. 

4.4  Script  Matching  and  Acquisition 

Script  matching  is  pan  of  the  "Event  Location"  and  "Event  Identification"  elements  of 
Figure  2.1.  These  functions  are  done  by  the  ScriptMatch  module  in  Figure  3.1.  Script 
acquisition  is  pan  of  the  "Knowledge  Acquisition"  clement  (Figure  2.1),  and  it  is  done  in 
the  SAS  module  (Figure  3.1). 

4.5  Event  Identification 

This  function  is  clearly  identified  in  Figure  2.1.  The  modules  used  for  this  function 
include  Eventid,  MERSY,  and  Sratio. 

4.6  Analyst  Review 

This  covers  the  "Interactive  Analyst  Review"  function  of  Figure  2.1.  The  software 
modules  include  all  those  listed  in  the  "Analyst  Review,"  "Display,"  and  "Form  Beams" 
boxes  in  Figure  3.1. 

4.7  Knowledge  Acquisition 

This  function  is  clearly  identified  in  Figure  2.1.  The  software  modules  implementing  it 
include  PerfV,  SAS,  and  iastalk  (Figure  3.1). 


4.2.  SIGNAL  PROCESSING 

As  described  in  Section  2.3,  the  initial  step  in  the  analysis  of  the  data  is  to  detect  signals  and 
compute  features  that  characterize  them,  and  this  is  done  by  the  SigPro  process  described  here. 
A  dataflow  description  is  given  in  Figure  4.1.  The  first  two  diagrams  (Figures  4.1a  and  b) 
show  the  context  and  external  interfaces.  The  two  major  functions  done  by  SigPro  are  signal 
detection  and  post-detection  processing,  and  these  are  described  in  Figures  4.1c  and  d. 

As  indicated  in  Figure  4.1a,  SigPro  is  initiated  by  a  command  from  an  "Executive"  process 
(startSigPro,  see  Section  3.3),  and  it  is  configured  by  parameters  in  the  "Quasi-Static  Data." 
SigPro  communicates  with  other  processes  via  IPC  messages  routed  through  a  "Dispatcher."  At 
the  next  level  of  decomposition  (Figure  4.1b),  we  show  that  detection  leads  to  selection  of 
waveform  "Segments"  for  post-detection  processing  to  extract  the  detection  attributes  aiid  other 
characteristics.  Further  decomposition  in  Figures  4.1c  and  d  shows  the  major  operations 
applied  to  the  data. 
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Figure  4.1a  Context  diagram  for  IAS  signal  processing. 


Figure  4.1b  Signal  processing  overview.  Boxes  2  and  3  are  expanded  in  subsequent 
dataflow  diagrams. 


raw  waveforms, 

raw  data  “*■  Read  *  R^w  Waveforms  Segments 

parameters  Waveforms  '~7  j 
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Figure  4.1c  A  dataflow  description  of  the  IAS  detector. 
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Figure  4. Id  A  dataflow  descripuon  of  IAS  post-detection  processes. 


The  SigPro  program  evolved  from  the  NORSAR  RONAPP  program  (Mykkeltveit  and  Bungum, 
1984).  While  the  data  handling  and  control  flow  were  redesigned,  most  of  the  subroutines  that 
operate  on  the  data  were  adapted  unchanged  from  RONAPP.  The  other  significant  changes  and 
additions  include; 

•  Beamforming  and  detection  using  available  horizontal  channels  has  been  added  to  SigPro. 

•  SigPro  computes  the  spectrum  of  each  detected  signal  and  a  preceding  noise  segment. 

•  The  f-k  power  contours  arc  analyzed  to  assign  an  estimate  of  the  error  in  the  slowness 
and  azimuth  estimates.  This  error  depends,  in  part,  on  a  measure  of  the  "quality"  of  the 
f-k  solution  which  is  determined  automatically. 

•  The  original  RONAPP  computed  f-k  at  a  single  frequency,  but  SigPro  (and  more  recent 
versions  of  RONAPP)  compute  f-k  averaged  across  a  band  of  frequencies. 

•  SigPro  computes  various  measures  of  the  polarization  of  the  detected  signal. 

In  the  remainder  of  this  section  we  describe  the  particular  algorithms  implemented  in  SigPro. 
However,  we  emphasize  that  the  modular  design  of  SigPro  isolates  the  major  algorithms  in 
modules  designed  to  be  upgraded  or  replaced  with  little  or  no  alteration  to  other  parts  of  the 
code. 

4.2.1.  Input  Data 

The  data  input  to  SigPro  include  the  raw  waveforms  obtained  from  the  "Disk  Loop"  (Figure 
3.1)  and  parameters  and  recipes  to  configure  SigPro  for  the  particular  array  being  processed. 
That  is,  applying  SigPro  to  data  from  a  different  array  is  easily  done  by  changing  the 
appropriate  quasi-static  data.  The  original  waveforms  arc  managed  with  the  .wfdisc  and  .w 
entities  in  Version  2.8  of  the  Center  for  Seismic  Studies  Database  Structurcst  (Brennan,  1988). 
The  quasi-static  data  are  in  tables  in  the  2.8  database  and  include  the  following; 

•  The  location  of  each  element  of  the  array. 

•  Recipes  specifying  details  of  the  quality  conu-ol  algorithms. 

•  Recipes  specifying  the  beams  to  be  calculated,  the  f-k  calculation,  the  spectrum 
calculation,  and  the  polarization  calculation. 

•  Coefficients  specifying  various  filters  available  for  use. 

•  Parameters  specifying  the  detection  threshold  for  each  filtered  beam. 


4.2.2.  Beamforming  and  Detection 

The  waveform  data  arc  acquired  by  SigPro  in  large  blocks  selected  by  SPServer  (Section  3.2), 
with  the  length  typically  varying  between  30  and  120  minutes.  SigPro  first  examines  the  data 
quality  in  4  second  segments  to  identify  and  repair  or  mask  bad  data.  The  latter  is  done  by 
NORSAR  subroutines  developed  by  Jan  Fyen.  Each  channel  is  examined  for  spikest  and 
.scries  of  zeroes  or  identical  data.  If  the  number  of  faulty  values  is  less  of  all  values  in  the 
segment,  the  faulty  values  are  repaired  by  setting  them  to  zero.  Otherwi.se,  the  channel  is 
masked  for  that  4-second  .segment  (i.c.,  it  is  excluded  from  subsequent  processing). 


+  Subsequently  called  "2.8  database." 

t  For  spike  detection  the  maxi.Tium  amplitude  within  the  4-sccond  segment  is  found  for  each  element 
of  the  array,  and  these  values  are  averaged  across  all  channels.  A  spike  Ls  declared  when  the  amplitude  of 
a  particular  sample  is  more  than  3  times  larger  than  this  mean  maximum  amplitude. 
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Specification  of  the  beams  to  be  computed  is  obtained  from  the  quasi-static  data  on  each 
initiation  of  SigPro.  The  particular  beam  set  applied  to  ARCESS  and  NORESS  during  the 
1989  operation  of  IAS  is  described  in  Table  4.1.  For  each  of  the  74  beams  we  give  the 
steering  azimuth  and  velocity,  filter  frequency  band,  filter  order  (for  a  Buttcrworth  filter),  beam 
type  (C  for  coherent  vertical  beam,  I  for  incoherent  vertical  beam,  H  for  beam  of  horizontal 
channels),  array  elements  included  in  the  beam,$  and  SNR  detection  threshold.  Selection  of 
the  vertical  beam  set  is  based  on  work  done  by  Kvacma  (1989).  Eight  of  these  beams  (#67 
through  #74)  are  selected  for  P  waves  from  the  major  Soviet  test  sites  at  Novaya  Zemlya  and 
Semipalatinsk,  and  the  other  62  are  selected  for  regional  phases. 

The  coherent  beams  are  formed  by  simple  delay-and-sum  operations,  followed  by  band  pass 
filtering.  For  the  incoherent  beams  each  channel  is  first  filtered,  then  rectified,  delayed  (if  the 
beam  is  steered)  and  summed.!  The  horizontal  beams  are  computed  by  simply  summing  all 
horizontal  channels  after  filtering  and  rectifying  (i.e.,  incoherent  beams).  The  computational 
time  required  for  a  beam  is  roughly  proportional  to  the  number  of  channels  filtered,  so  the 
incoherent  beams  are  much  more  expensive  to  compute.  Note  that  relatively  few  of  them  are 
included  in  the  IAS  beam  set. 

An  STA/LTA  detector  is  applied  to  each  of  the  computed  beams.  The  STA  is  updated  every 
time  sample  (0.025s  sampling  rate)  as  the  running  average  of  the  rectified  beam  amplitude  over 
a  1 -second  time  window.  The  LTA  is  computed  from; 

Ita^  =  ItaM  (1.  -  2’")  +  stCM  2""- 

For  IAS  n=5  and  the  ha  is  updated  each  0.5  seconds,  making  the  LTA  an  average  over  roughly 
30  seconds. 

For  each  beam  the  SNR  =  STA/LTA,  and  a  detection  is  declared  when  SNR  exceeds  the 
specified  threshold  (Table  4.1).  Often,  numerous  beams  exceed  their  detection  threshold  in  the 
same  4-second  time  segment  The  beam  with  the  largest  value  of  SNR  is  taken  as  the 
"detecting"  beam.  The  earliest  detecting  beam  in  this  time  segment  also  plays  a  role  in 
subsequent  processing,  since  its  detection  time  is  used  as  the  initial  estimate  for  the  onset  time 
(see  Section  4.2.3. 1).  A  beam  in  a  detecting  state  remains  in  that  state  until  the  SNR  stays 
below  the  beam  threshold  for  an  entire  4-second  segment. 

The  result  of  this  processing  is  a  detection  list  including  the  STA,  SNR,  and  detection  time 
This  is  passed  to  the  next  stage,  the  px)st-detection  processing. 

4.2.3.  Post-Detection  Processing 

As  shown  in  Figure  4. Id,  this  part  of  the  processing  has  four  major  elements.  Each  of  these  is 
described  in  subsequent  sub-sections. 

4.2.3.1,  Analyze  Beams 

The  objectives  here  are  to  refine  the  detection  omset  time  and  estimate  the  dominant  frequency 
and  amplitude  of  the  detecting  beam  and  to  determine  the  amplitude  of  the  detection  on  a  set 
of  standard  beams.  The  detection  time  onset  (time)  is  estimated  with  the  algorithm  used  in 
RONA.PP  (Mykkeltvcit  and  Bungum,  1984)  which  analyzes  the  waveform  peaks  and  troughs 
near  the  detection.  In  most  cases  the  waveform  analyzed  is  the  "detecting”  (i.e.,  largest  SNR) 

t  The  array  geometry  is  shown  in  Figure  1.1.  The  center  element  is  AO,  and  there  are  ?  5,  7  and  9 
elements  in  the  A.  B,  C  and  D  rings.  Three-component  sensors  are  at  AO  and  in  the  C  ring. 

+  Steering  delays  are  not  used  in  the  incoherent  beams  of  Table  4.1,  since  they  do  not  improve  SNR  at 
these  frequencies  and  for  this  element  spacing. 
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TABLE  4.1 

IAS  Beam  Deployment 


# 

BEAM 

(Bmn) 

VEL 

(km/s) 

FILTER 

(Hz) 

FILTER 

ORDER 

AZIMUTH 

DEGREES 

BEAM 

TYPE 

THRESHOLD 

RING 

SUBSET 

1 

221 

oo 

2.0-4.0 

3 

0. 

H 

2.4 

AO 

C 

o 

223 

oo 

5.0-10.0 

*’ 

0. 

H 

2.4 

AO 

c 

3 

226 

oo 

3.5-5.5 

0. 

H 

2.4 

AO 

c 

4 

228 

oo 

8.0-16.0 

0. 

H 

2.5 

AO 

c 

5 

201 

oo 

1. 0-3.0 

” 

0. 

C 

4.0 

AO 

C  D 

6 

202 

oo 

1.5-3.5 

” 

0. 

C 

4.0 

AO 

C  D 

7 

207 

oo 

8.0-16.0 

’• 

0. 

C 

4.5 

AO  A  B 

8 

220 

oo 

1.5-2.5 

2 

0. 

1 

2.5 

AO 

C 

9 

225 

oo 

3.5-5.5 

3 

0. 

1 

2.4 

AO 

C 

10 

254 

oo 

2.0-4.0 

” 

0. 

C 

4.0 

AO 

C  D 

11 

261 

oo 

2.5-4.5 

0. 

c 

4.0 

AO 

BCD 

12 

288 

oo 

3.0-5.0 
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beam,  but  the  quasi-static  data  provide  for  selection  of  a  different  beam  when  appropriate.  In 
IAS  the  quasi-static  data  select  for  analysis  the  closest  vertical  coherent  beam  (i.e.,  similar  or 
identical  filter  and  element  subset)  when  the  detecting  beam  is  incoherent  (vertical  or 
horizontal). 

SigPro  also  provides  an  estimate  of  the  error  in  time.  This  varies  from  4.0  seconds  when  the 
SNR  on  the  detecting  beam  is  at  the  threshold  to  1.0  seconds  when  it  is  5  or  more  times  larger 
than  the  threshold.  This  estimate  is  treated  as  the  la  error  bound  on  the  onset  time  in 
subsequent  location  calculations. 

A  consistent  measure  of  amplitude  is  needed  for  subsequent  stages  of  the  interpretation.  Thus, 
a  set  of  standard  beams  is  designated  (in  IAS  these  are  beams  5,  7,  10,  14,  16,  17  of  Table 
4.1),  and  the  maximum  STA  is  determined  for  each  within  a  four-second  window  surrounding 
the  time  determined  from  the  waveform  analysis.  These  STA  and  the  corresponding  LTA  are 
stored  in  the  DBMS. 


4.2.3.2.  Frequency-Wavenumber  Analysis 

The  f-k  calculation  is  configured  with  quasi-static  data,  and  here  we  describe  how  it  is  done  in 
IAS.  For  each  detection  the  f-k  power  spectrum  is  computed  for  a  3  second  segment  starting 
1.1  seconds  before  the  onset  time.  The  computation  is  done  with  all  available  (up  to  25  for 
NORESS  and  ARCESS)  vertical  channels  after  band-pass  filtering  each  channel.  The  wide¬ 
band  f-k  algorithm  of  Kvacma  and  Doombos  (1986)  is  used.  The  power  spectrum  (P)  is 
computed  from; 


Pisx^)  = 


tchsxftck 

S  (  Z  exp'  ^  xy 

p=fi 

/c/2  ichs^k 

^  nch  Y,  FifMhf 

frj\  ktel 


where  sx  is  the  E-W  slowness,  sy  the  N-S  slowness,  F(f,ich)  the  Fourier  transform  of  channel 
ich  at  frequency  f,  x  &  y  the  E-W  and  N-S  coordinates  of  the  channel  relative  to  the  array 
reference  station,  fl  and  f2  the  low  and  high  frequency  limits,  and  nch  the  number  of  channels. 

The  frequency  band  for  the  calculation  is  one  octave  centered  over  the  dominant  frequency 
determined  by  the  waveform  analysis  described  above.  The  resolution  is  41x41  points  and  .02 
sec/km  in  slowness.  Estimates  for  the  azimuth  and  slowness  of  the  detected  signal  are 
obtained  by  interpolation  around  the  peak  power.  The  error  in  these  estimates  depends  on  the 
wavenumber  resolution  in  this  frequency  band  and  the  quality  of  the  particular  solution.  To 
estimate  the  resolution,  we  analyze  the  theoretical  beam  pattern  to  find  the  difference  between 
the  azimuth  and  slowness  values  at  the  peak  power  and  their  values  at  1  dB  below  the  peak. 
For  a  symmetric  array  like  NORESS  the  1  dB  contour  is  a  circle.  If  the  radius  of  this  circle  is 
5k,  the  errors  in  azimuth  (5a)  and  veiOCity  (5v)  at  the  center  frequency  arc: 


5a 


sin 
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(7)6/t 
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and 


5k 


To  account  for  additional  errors  caused  by  noise,  interfering  signals,  and  deviation  from  the 
plane-wave  assumption,  we  also  compute  an  f-k  quality  measure,  fkq.  For  this  we  follow 
NORSAR  conventions  (Ringdal,  personal  communication)  and  set  fkq  =/  when  the  amplitude 
of  the  second  highest  peak  is  more  than  6  dB  less  than  that  of  the  highest  peak  (maximum  f-k 
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power).  The  fkq  is  2.  3,  and  4  when  the  difference  between  the  first  and  second  peaks  is  4  to 
6  dB,  2  to  4  dB,  and  0  to  2  dB,  respectively.  An  F-statistic  (fsiai)  is  also  computed  (Kvasma, 
personal  communication)  to  characterize  the  coherency  of  the  f-k  power  spectrum  as  follows: 


fstat  = 


(Pave  ~  ax) 


where  is  the  maximum  f-k  power,  and  is  the  average  power  in  the  n  vertical-channel 
time-series.  The  fstat  can  have  any  positive  value,  but  the  values  archived  range  between  0  and 
99.99,  with  the  latter  representing  all  fstat  >  99.99. 

The  resolution  error  and  fkq  are  combined  to  obtain  slowness  and  azimuth  error  estimates  used 
in  subsequent  parts  of  the  IAS  processing.  When  fkq  =1,  the  resolution  error  is  interpreted  to 
be  2  standard  deviations  (2a).  When  fkq-2  the  error  is  1.5o,  and  when  fkq=3,  the  resolution 
error  is  interpreted  to  be  a.  Detections  with  fkq=4  are  considered  to  be  essentially  noise,  and 
they  are  not  used  in  further  processing.  The  correspondence  between  these  ad  hoc  error 
estimates  and  a  statistically  meaningful  standard  deviation  is  not  supported  rigorously,  and  the 
validity  of  the  estimates  will  be  reviewed  when  enough  operational  experience  is  accumulated. 


4.2.3.3.  Spectra  Computation 

Spectra  are  calculated  for  each  detection  and  a  preceding  noise  segment  using  the  method  of 
Bache  et  al.  (1985).  The  signal  spectrum  is  calculated  for  a  5  second  window  starting  0.3 
seconds  before  the  onset  time  on  the  center  element  of  the  array  (no  corrections  arc  made  for 
time  delays  across  the  array).  Power  spectra  arc  computed  for  each  vertical  channel  and 
averaged.  A  similar  power  spectrum  is  computed  for  a  5-second  noise  segment  selected  12 
seconds  before  the  onset  time.  Both  signal  and  noise  amplitude  spectra  are  saved  for  future 
processing. 


4.2.3.4.  Polarization  Analysis 

As  with  the  other  post-detection  processes,  the  parameters  controlling  details  of  the  polarization 
analysis  are  specified  by  quasi-static  data,  and  they  are  easily  changed.  Here  we  describe  the 
details  of  the  polarization  calculations  done  during  IAS  operation  in  1989.  The  method  is  that 
of  Jurkevics  (1988),  modified  for  automated  application  in  SigPro.  In  this  method  the  time- 
domain  polarization  ellipse  is  computed  by  solving  the  eigenproblcm  for  the  covariance  matrix. 
Data  from  the  four  three-component  sensors  at  NORESS  and  ARCESS  are  combined  by 
averaging  the  individual  covariance  matrices  before  solving  the  eigenproblem. 

The  polarization  analysis  is  performed  on  an  8  second  data  segment  starting  4  seconds  before 
the  onset  time  of  the  signal  at  the  center  element  of  the  array.  There  is  no  lime  shifting  to 
account  for  phase  velocities  across  the  array,  though  this  is  possible  at  this  stage  of  the 
processing  using  results  from  the  f-k  analysis.  Numerical  experiments  done  by  Jurkevics 
(1988)  indicate  that  the  covariance  averaging  is  not  very  sensitive  to  time  delays  across  the 
array  at  frequencies  of  interest. 

The  covariance  matrices  are  computed  in  the  time  domain  for  a  series  of  frequency  bands,  then 
normalized  and  averaged  to  obtain  a  wide-band  estimate.  For  IAS  the  emphasis  is  on  regionuj 
signals,  and  the  selected  frequency  bands  arc  1-2,  2-4,  4-8,  and  8-16  Hz.  In  each  frequency 
band  the  covariance  matrices  are  calculated  for  each  seismometer  for  thirteen  2-second 
overlapping  (by  1.5  seconds)  tapered  lime  windows.  These  arc  then  averaged  across  all 
available  three -component  seismometers  in  the  array  to  obtain  covariance  matrices  for  the  4 
frequency  bands  and  13  time  samples.  A  pre-event  noise  segment  selected  20  .seconds  before 
the  onset  lime  is  processed  the  same  way,  and  the  noise  in  each  frequency  band  N(0  is  taken 
as  the  maximum  three-component  amplitude  occuring  in  the  13  time  samples.  In  each 
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frequency  band  a  signal/noise  (SNR)  is  computed  as  the  ratio  of  the  maximum  three- 
component  amplitude  occuring  in  the  signal  to  the  maximum  three-component  amplitude 
occuring  in  the  noise.  The  covarience  matrices  for  those  frequency  bands  that  are  above  a 
specified  SNR  threshold  (1.5)  are  then  normalized  (by  the  trace)  and  averaged  to  obtain  wide¬ 
band  covariance  matrices  for  the  13  time  samples.  The  polarization  ellipsoid  is  then  computed 
for  each  of  these  13  times. 

Various  parameters  are  calculated  from  the  eigenvalues  of  the  polarization  ellipsoid  to 
characterize  the  panicle  motion.  Several  parameters  are  calculated  from  the  lime  window  with 
the  maximum  rectilinearity.  These  are  the  rectilinearity,  the  apparent  incidence  angle,  and  the 
time  of  the  center  of  this  window.  Also,  the  window  with  the  maximum  three-component 
amplitude  is  found,  and  the  horizontal/venical  amplitude  ratio  and  incidence  angle  of  the 
smallest  eigenvalue  are  saved  with  the  time  of  the  center  of  that  window.  Also  saved  is  the 
maximum  SNR  found  for  the  four  frequency  bands. 


4.2.4.  Output  Data 

The  data  output  by  SigPro  for  each  delected  signal  are  as  follows; 

•  The  onset  time,  amplitude  and  period  of  the  detected  signal. 

•  The  STA  and  LTA  (short-term  and  long-term  averages)  at  the  onset  lime  for  a 
standard  beam  set. 

•  The  "detecting"  beam;  i.e.,  maximum  signal/noise  (SNR)  beam. 

•  The  azimuth  and  slowness  determined  from  analysis  of  the  f-k  power  contours. 

•  Error  estimates  for  the  onset  time  (based  on  SNR),  azimuth  and  slowness  (based  on 
analysis  of  the  f-k  power  contours). 

•  Measures  of  the  f-k  solution  quality. 

•  The  f-k  power  contours. 

•  The  Fourier  spectrum  of  the  signal  and  a  preceding  noise  segment. 

•  Panicle-motion  attributes  obtained  from  polarization  analysis  of  the  signal. 
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4J.  EXPERT  SYSTEM  FOR  LOCATION 

Section  2.3  described  the  conceptual  design  of  the  expert  system  which  interprets  the  output  of 
SigPro  to  locate  seismic  events,  and  this  is  done  in  the  ASSESS  software  module  (Figure  3.1). 
In  this  section  we  describe  the  ASSESS  inference  structure  and  the  spiecific  rules  and 
procedures  (the  "knowledge  base")  used  for  IAS  processing  during  October-December,  1989.  A 
key  advantage  of  an  expert  system  software  architecture  is  the  separation  of  the  knowledge 
base  from  the  inference  structure,  so  it  is  relatively  easy  to  add  new  knowledge  as  it  is 
obtained.  Thus,  the  details  of  the  rules  and  procedures  described  here  are  changing  with 
experience. 

The  reasoning  process  employed  by  ASSESS  is  sketched  in  Figure  4.2.  The  input  are  the 
"features"  computed  by  SigPro.  The  figure  highlights  the  fundamental  division  between 
"single-array  processing"  which  is  done  first  and  considers  only  the  information  provided  by 
one  array,  and  "network  processing"  which  combines  information  from  all  stations  in  the 
network  (two  arrays  in  IAS).  Within  the  single-array  processing  the  reasoning  proceeds  in 
order  through  the  four  major  elements  shown.  This  provides  a  natural  segmentation  of  the 
knowledge  base  that  reduces  the  scope  (i.e.,  number  of  relevant  rules)  of  the  reasoning  at  any 
given  time.  The  single-array  processing  provides  a  tentative  identification  of  each  detected 
signal  and  a  single-array  location  for  appropriate  groups  of  signals.  The  reasoning  in  "network 
processing"  involves  an  iterative  comparison  of  results  from  different  stations  to  seek 
corroborating  data  and  backtracking  to  revise  earlier  solutions  (including  those  from  the 
single-array  processing).  In  subsequent  sections  we  describe  the  rules  and  procedures  within 
each  of  these  major  divisions. 

TTie  reasoning  strategy  of  ASSESS  generates  and  explores  hypotheses  in  a  depth-first  manner 
starting  from  the  most  simple  explanations  of  the  data.  That  is,  at  each  stage  of  the  processing 
shown  in  Figure  4.2  the  simplest  explanation  of  the  data  is  hypothesized  (e.g.,  all  phases  from 
nearly  the  same  azimuth  arc  from  the  same  event),  and  knowledge  is  used  to  search  for 
contradictions  to  this  hypothesis  (e.g.,  there  is  a  P  phase  after  an  S  phase,  so  there  cannot  be 
only  one  event).  When  contradictions  are  encountered,  the  hypothesis  is  retracted,  and  the  next 
simplest  hypothesis  is  examined  (e.g.,  there  are  two  events).  This  strategy  works  well  for  the 
regional  seismic  problem,  and  it  matches  reasonably  well  the  reasoning  process  applied  by  a 
human  analyst. 


4J.1.  Features  --  Data  Input  to  ASSESS 
The  spocific  data  input  to  this  program  include; 
sta  Station  identifier 

bmtyp  The  "detecting"  beam  (Section  4.2.2) 

Slav  Short-term  average  from  the  "detecting"  beam  (Section  4.2.2) 

snr  Signal/noise  on  the  "detecting"  beam  (Section  4.2.2) 

time  Onset  time  from  the  waveform  analysis  (Section  4.2.3. 1) 
deltim  Assumed  standard  deviation  on  the  onset  time  (Section  4.2.3. 1) 

amp  Short-term  average  from  standard  beam  #17  (Table  4.1),  a  2-4  Hz  incoherent 
beam  of  the  AO  and  C  ring  vertical  channels  (Section  4.2.3. 1) 

seaz  Azimuth  from  f-k  processing  (Section  4.2.3.2) 

delaz  Assumed  standard  deviation  on  the  azimuth  (Section  4. 2. 3. 2) 

vel  Inverse  of  the  slowness  from  f-k  processing  (Section  4. 2. 3.2) 
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Fifiure  4.2.  A  high-level  view  of  the  reasoning  process  employed  by  ASSESS  is  shown.  The 
major  steps  in  the  single-station  processing  are  shown  in  the  order  they  are  taken.  The 
network  processing  is  more  complex,  and  it  is  sketched  in  somewhat  more  detail  in  Figure  4.3. 


fkqual  f-k  solution  quality  (the  fkq  of  Section  423.2) 
rect  Rectilinearity  from  polarization  analysis  (Section  4.2.3.4) 
inangl  P  incidence  angle  from  polarization  analysis  (Section  4.2.3.4) 
hvrat  Horizontal/vertical  ratio  from  polarization  analysis  (Section  4.2.3.4) 
inangS  Short-axis  incidence  angle  from  polarization  analysis  (Section  4.2. 3.4) 


43.2.  Single-Array  Processing 

ASSESS  takes  as  input  a  detection  list  ordered  by  time,  but  the  single-array  reasoning  described 
here  takes  account  of  the  array  identifier  (sta),  effectively  considering  only  detections  from  the 
same  array.  This  single-array  reasoning  process  and  knowledge  are  described  in  this  section. 

43.2.1.  Initial  Phase  Identification 

A  major  simplification  of  the  interpretation  task  is  possible  with  data  from  NORESS-type 
arrays  because  the  phase  velocity  determined  from  the  f-k  analysis  provides  a  reliable 
separation  between  P-type  and  S-type  phases.  As  noted  by  Mykkeltveit  and  Bungum  (1984) 
and  verified  by  subsequent  experience,  the  phase  velocity  6  km/sec  provides  almost  perfect 
separation  between  regional  Pn  and  Pg  and  regional  Sn  and  Lg.  In  our  experience  there  are  no 
exceptions  to  this  rule  fov  fkqual  <  4.  For  this  and  other  reasons,  detections  vi'wh  fkqual=  4  are 
marked  as  "noise"  and  are  not  used  in  the  interpretation.  The  demarkation  between  teleseismic 
and  regional  P  is  not  so  simple,  but  we  can  assert  with  very  high  confidence  that  signals  with 
estimated  phase  velocities  >  14  km/sec  are  from  teleseismic  events.  At  the  other  end  of  the 
velocity  range,  signals  with  phase  velocities  <  2.8  km/sec  are  almost  always  noise  or  late  coda 
detections  (not  useful  for  location),  so  they  can  safely  be  marked  as  noise. 

In  summary,  at  this  first  stage  of  the  interpretation  we  use  the  estimated  phase  velocity  {vet)  to 
assign  the  initial  phase  identification  to  each  detected  signal.  The  identification  is: 

N  if  vel  <  2.8 
S  if  2.8  <vel<6 
P  if  6  <  vc/  S  14 
T  if  vel  >  14 

Some  of  the  signals  called  P  will  actually  be  teleseisms,  and  some  of  the  phases  called  S  will 
actually  be  noise.  Some  of  these  non-regional  signals  could  be  identified  by  applying  more 
knowledge  (e.g.,  frequency  content),  but  this  only  reduces  the  number  of  phases  that  are 
candidates  for  later  identification  as  Pn,  Lg,  etc.  In  the  initial  implementation  this  advantage 
did  not  warrent  the  added  complexity. 

43.2.2.  Detection  Grouping 

The  next  step  in  the  interpretation  is  to  form  groups  of  phases  that  appear  to  be  generated  by 
the  same  event.  Only  phases  identified  as  P  or  S  are  considered.  The  first  step  is  to  form  an 
"initial  detection  grouping"  to  provide  a  focus  of  attention.  The  rule  is: 

•  Form  Initial  Detection  Grouping 

Each  new  detection  is  considered  for  inclusion  in  existing  groups.  It  is  included  if 
it  occurs  within  6  minutes  of  the  last  detection  in  a  group  and  its  azimuth  overlaps 
(within  ±2.5*delaz  bounds  on  each)  with  the  azimuth  of  the  first  detection  in  the 
group.  Otherwise,  a  new  group  is  formed. 
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The  number  of  events  contributing  phases  to  this  "initial  detection  grouping"  could  be  as  few 
as  one,  or  as  many  as  there  are  separate  P  and  S  phases  in  the  group.  The  simplest 
explanation  is  that  there  is  only  one  event,  and  this  is  taken  as  the  initial  hypothesis. 
Contradictions  to  this  hypothesis  are  sought,  indicating  that  there  are  at  least  two  events  in  the 
group.  In  the  1989  implementation,  the  maximum  number  of  events  ASSESS  will  find  in  the 
"initial  detection  grouping"  is  two.  This  becomes  a  limitation  when  there  are  three  or  more 
events  at  the  same  azimuth  contributing  phases  spaced  by  no  more  than  6  minutes.  New  rules 
will  be  introduced  to  deal  with  this  in  future  versions.  The  tests  applied  to  determine  whether 
there  are  one  or  more  events  in  the  initial  detection  grouping  are  as  follows; 

•  Test  for  P  after  S 

A  P  phase  occuring  after  an  S  phase  must  be  from  a  different  event. 

•  Inconsistent  P  detections 

Find  the  first  P  and  largest  S  in  the  group.  Using  the  travel-time  tables  assuming 
the  first  P  is  Pn  and  the  largest  S  is  Lg,  determine  the  time  separation  between  Pn 
and  Pg  (Pn-Pg)  and  Sn  and  Lg  (Sn-Lg).  If  the  time  separation  between  any  two  P 
phases  is  more  than  \.5*(Pn-Pg),  these  two  phases  are  assumed  to  be  from  different 
events. 

•  Inconsistent  S  detections 

Use  the  Sn-Lg  defined  in  the  previous  mle.  If  the  time  separation  between  any  two 
S  phases  is  more  than  1.5*(Sn-Lg),  these  two  phases  are  assumed  to  be  from 
different  events. 

The  next  step  is  to  assign  each  P  and  S  phase  to  an  "event  group."  When  the  previous  mles 
conclude  that  there  is  more  than  one  event  contributing  detections  to  the  "initial  detection 
grouping,"  there  are  often  many  potentially  correct  combinations  of  P  and  S  phases.  The 
objective  of  the  next  set  of  rules  is  to  find  the  combination  most  likely  to  be  correct.!  A 
significant  simplification  of  the  problem  is  made  by  collecting  one  or  more  closely-spaced 
phases  of  the  same  type  (P  or  S)  into  bins.  Individual  phases  in  the  bins  retain  their  individual 
identity,  but  it  is  sometimes  convenient  to  treat  a  bin  as  a  single  phase  (e.g.,  a  phase  and 
following  coda  detections).  The  rules  for  forming  the  bins  and  associating  them  with  specific 
events  are  as  follows; 

•  P  bin  rule  #7 

There  is  one  P  bin  for  each  "different"  event  from  the  Inconsistent  P  detections 
rule.  This  P  bin  includes  all  P  consistent  with  the  first  P  in  the  bin. 

•  P  bin  rule  #2 

When  there  are  two  events  and  two  or  more  P  waves  not  separated  by  P  bin  rule 
#7,  the  last  P  is  placed  in  a  second  P  bin. 

•  S  bin  rule  #7 

There  is  one  S  bin  for  each  "different"  event  from  the  Inconsistent  S  detections  mle. 
This  S  bin  includes  all  S  consistent  with  the  first  S  in  the  bin,  and  overlapping  with 
largest  S  in  azimuth  (azimuths  agree  within  ±2.5*delaz  bounds  on  each).  Arrivals 
that  do  not  satisfy  these  time  and  azimuth  constraints  arc  placed  in  a  second  S  bin. 

•  S  bin  rule  #2 

When  there  are  two  events  and  two  or  more  S  waves  not  separated  by  S  bin  rule 
#7,  the  last  S  is  placed  in  a  second  S  bin. 


t  In  many  cases  it  is  not  possible  even  for  a  skilled  human  analyst  to  unravel  mixed  signals  with  high 
confidence  using  only  data  from  a  single  array.  Deicction.s  from  another  station  or  array  are  needed. 
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These  rules  result  in  >  1  P  bins  and  >  1  S  bins.  To  separate  these  into  events  we  apply  the 
following  rules: 

•  Bins  of  only  one  type  (P  or  S) 

All  phases  are  marked  unassociated,  and  there  will  be  no  event  at  the  single-array 
stage  of  the  processing. 

•  One  P  bin  or  only  one  S  bin  and  >  1  bin  of  the  other  type 

There  is  one  event.  If  there  is  only  one  P  bin,  it  is  associated  with  the  S  bin 
containing  the  largest  amplitude  (amp)  S,  and  the  phases  in  all  other  S  bins  are 
marked  unassociated.  If  there  is  only  one  S  bin,  it  is  associated  with  the  earliest  P 
bin,  and  the  phases  in  all  other  P  bins  are  marked  unassociated. 

•  >  3  P  bins  and  >  3  S  bins 

Associate  the  first  P  bin  and  the  S  bin  containing  the  largest  amplitude  S  (amp). 
Mark  all  phases  in  other  bins  unassociated. 

If  there  arc  >  2  P  bins  and  2  S  bins  or  >  2  S  bins  and  2  P  bins,  there  is  assumed  to  be  two 
events.  Phases  are  associated  to  form  these  two  events  using  the  following  rules: 

•  P  after  S 

A  P  that  follows  an  S  is  the  first  P  phase  for  the  second  event. 

•  Complete  event  group  preference 

A  complete  event  group  must  have  at  least  one  P  bin  and  one  5  bin.  When  there  are 
two  of  each  reject  combinations  that  leave  unassociated  phases  or  bins. 

•  Associate  phases  or  bins  using  amplitude  or  azimuth 

P  and  5  bins  are  separated  with  amplitude  if  the  largest  amplitude  (amp)  in  the  two 
bins  differs  by  at  least  a  factor  of  two.  In  this  case  the  largest  P  bin  is  associated 
with  the  largest  S  bin.  Otherwise,  associate  the  P  bin  and  S  bin  which  have 
maximum  amplitude  phases  with  azimuths  least  different. 

At  the  end  of  this  stage  of  processing  ASSESS  has  the  phases  divided  into  event  groups  with 
each  containing  at  least  one  P  and  one  S  phase.  Phases  not  included  in  an  event  group  may 
later  be  associated  with  events  during  the  network  processing. 

4.3.2.3.  Phase  Identification 

At  least  two  phases  must  be  identified  as  Pn,  Pg,  Sn,  Lg,  or  Rg  (together  with  their  azimuths) 
to  locate  an  event  with  data  from  a  single  array.  At  the  phase  identification  stage  at  least  two 
of  these  "locating  phases"  arc  selected  from  the  phases  in  each  event  group.  The  appropriate 
rules  vary  significantly  with  region,  and  the  current  set  is  only  appropriate  for  the  region 
around  NORESS  and  ARCESS. 

These  rules  separate  the  event  groups  into  three  classes  depending  on  their  apparent  range  from 
the  array.  This  is  based  on  S-P,  which  is  the  arrival  time  separation  between  the  first  P  and 
largest  S  in  the  event  group.  The  rules  also  use  the  apparent  polarization  which  is  represented 
by  integers  (Ppolar  and  Spolar)  computed  from  rect,  inangl,  hvrat,  and  inang3  as  indicated  in 
the  tables  below.  When  snr^,  Ppolar  and  Spolar  are  set  to  zero  (undetermined  polarization). 
Otherwise,  the  negative  values  indicate  Pg  or  Lg  polarization,  while  positive  values  indicate  FYi 
or  Sn  polarization.  The  larger  the  value,  the  stronger  the  polarization. 
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The  phase  identification  rules  arc  listed  below,  divided  into  the  three  classes  of  S-P  separation. 

□  E\ent  groups  with  S-P  <  30  sec 

•  Largest  S  =  Lg 

•  1st  P  =  Pg 

□  Event  groups  with  30  sec  <  S-P  <  75  sec 
Pn  or  Pg: 

Case  1:  only  1  P 

•  If  Ppolar  <  0,  then  P  =  Pg 

•  If  Ppolar  >  0.  then  P  =  Pn 

Case  2:  Two  or  more  P  and  1st  P  is  largest 

•  If  S-P  <  40  sec  and  1st  P  Ppolar  <  0,  then  1st  P  =  Pg 

•  If  S-P  >  40  sec  or  1st  P  Ppolar  >  0  then,  1st  P  =  Pn 

Case  3:  Two  or  more  P  and  1st  P  not  largest 

•  1st  P  =  Pn 

•  If  the  time  of  largest  P  <  12  seconds  later  than  time  of  1st  P  and  largest  P  Ppolar  < 

0,  then  largest  P  =  Pg 

Sn  or  Lg: 

Case  1:  1st  S  detected  on  horizontal  beam  with  Spolar  >  0 

•  1st  S  =  Sn 

•  If  the  largest  S  is  not  the  1st  S  and  has  time  S  within  10  seconds  of  the  predicted  Lg 
time  (Pn  or  Pg  and  Sn  are  already  identified),  then  largest  S  =  Lg 

•  If  largest  S  time  is  more  than  10  seconds  from  the  predicted  Lg  time  and  S  with 
smallest  Spolar  (if  tied,  select  S  with  largest  amp)  has  Spolar  <  0  and  time  within  10 
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Sn  or  Lg 

Case  1:  All  S  detections  are  within  20  seconds 

•  If  any  S  detected  on  horizontal  beam  with  Spolar  >  0,  then  1st  S  =  Sn 

•  If  any  S  detected  on  horizontal  beam  or  any  S  has  Spolar  >  0,  then  1st  S  =  Sn 

•  If  no  S  detections  on  horizontal  beam  or  no  S  with  Spolar  >  0  and  1st  S  seaz  between 
200  and  360  degrees  at  NORESS  (100  and  250  degress  at  ARCESS),  then  1st  S  =  Sn 

•  If  no  S  detections  satisfy  the  above  conditions,  then  Largest  S  =  Lg 

Case  2:  S  detections  separated  bv  more  than  20  seconds 
Separate  the  S  detections  into  two  sets  at  the  largest  gap. 

•  If  first  set  has  any  S  detected  on  horizon  al  beam  or  with  Spolar  >  0,  then  1st  S  =  Sn 

•  If  Spolar  <  0  for  any  S  in  2nd  set,  then  S  with  smallest  Spolar  (largest  amp  if  tie)  in 
2nd  set  is  Lg 

i  1  argest  S  in  2nd  set  is  Lg 

4_3.2.4.  Location 

Seismic  locations  are  computed  with  a  version  of  the  the  TTAZLOC  program  (Bran  and 
Bache,  1988)  convened  into  a  function  (called  LoeSAT)  within  ASSESS.  This  program  module 
is  used  for  all  locations  (single-array  processing  and  network  processing)  in  ASSESS,  as  well  as 
elsewhere  in  the  system  (e.g.,  LoeSAT  is  embedded  in  ARS,  see  Section  4.6).  LoeSAT  uses 
backazimuth  estimates,  arrival-time  data,  and  associated  uncertainties  in  a  least-squares-inverse 
location  algorithm.  T))e  data  input  include  the  array  locations,  travel-time  tables  for  the  phases 
of  interest  (Pn.  Pg,  Sn,  Lg,  Rg),  and  the  arrival-time  and  azimuth  data  {time,  deltim  seaz, 
delaz)  for  each  phase  associated  with  the  event. 

The  output  returned  by  the  LoeSAT  module  includes  the  location  solution  Qatituue,  longitude, 
and  origin  timef)  and  the  90%  confidence  error  ellipsoid.  Also  returned  are  the  s’ation-to-event 
location  distance  and  azimuth  for  each  locating  station  and  the  travel-time  and  azimuth 
residuals  for  each  datum  used  in  the  location  calculation. 

The  Bratt  and  Bache  (1988)  location  procedure  is  an  adaptation  of  the  Jordan  and  Sverdrup 
(1981)  formulation  which  allows  the  use  nf  both  a  priori  (deltim  u,id  delaz)  and  a  posteriori 
(the  solution  residuals)  information  about  the  data  uncertainties.  Their  relative  contribution  is 
controlled  by  the  parameters  K  and  In  the  1989  MS  operation  the  values  used  were  K=8 
and  5/  =  1.5.  These  values  make  the  confidence  ellipsoids  much  more  dependent  on  the 
assigned  variances  than  on  the  solution  residuals. 

The  Pn  and  Sn  travel-time  curves  are  computed  from  a  P-wave  model  provided  by  Mykkeltveit 
(pcrs-jnal  communication)  shown  below.  The  S-wavc  velocities  in  the  crust  are  obtained  by 
assuming  a  Poisson  solid,  and  the  mantle  S  velocities  were  estimated  by  Henry  Swanger 
(SAIC)  from  102  events  recorded  at  NORESS  and  ARCESS. 


t  In  lAS  the  depth  is  constrained  to  zero  for  all  location  calculations. 
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Thickness 
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Vp 

(km/sec) 

Vs 
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16.0 

6.20 

3.58 

24.0 

6.70 

3.87 

15.0 

8.10 

4.60 

— 

8.23 

4.68 

Other  phases  are  assumed  to  have  constant  group  velocity  as  follows: 

Pg  -  6.20  km/sec 
Lg  -  3.55  km/sec 
Rg  -  3.00  km/sec 

This  model  is  most  appropriate  for  paths  from  NORESS  to  the  east.  Paths  to  the  west  and  to 
ARCESS  are  known  to  be  different,  but  no  attempt  is  made  to  account  for  these  differences  in 
the  first  operational  version  of  IAS.  Data  obtained  by  operating  IAS  for  an  extended  period 
will  allow  development  of  excellent  travel-time  curves  for  the  region. 


4.3.3.  Network  Processing 

At  this  stage  ASSESS  has  interpreted  the  data  from  each  array  separately.  Noise  detections 
have  been  noted  and  removed  from  further  consideration,  teleseisms  have  been  identified,  and 
regional  phases  are  identified  as  P  or  S.  These  "initial  phase  identification"  decisions  cannot 
be  changed  by  subsequent  processing  with  ASSESS  (as  currently  implemented).  Many  of  the  P 
and  S  phases  are  associated  with  events,  and  each  event  includes  at  least  one  defining  P  (Pn  or 
Pg)  and  at  least  one  defining  S  (Sn  or  Lg).t  An  arbitrary  number  of  other  P  and  S  phases  may 
also  be  a-ssociated  with  an  event,  and  most  of  them  are  detections  in  the  coda  of  the  defining 
phases.  The  detection  list  also  includes  many  P  and  S  phases  that  are  not  associated  with  an 
event,  and  these  are  called  "unassociated  P"  (or  S). 

The  objective  of  "network  processing"  is  to  fuse  the  information  from  the  stations  in  the 
network  (in  this  case,  two  arrays)  to  obtain  a  complete  interpretation  of  the  data.  The  general 
concept  for  the  processing  involves  three  steps;  (1)  start  with  solutions  from  one  array;  (2)  seek 
collaboration  from  observations  at  the  other  array;  and  (3)  resolve  inconsistencies  by 
backtracking  to  change  earlier  decisions.  The  goal  is  a  consistent  explanation  of  as  many 
phases  as  possible.  The  processing  requires  computation  of  many  location  solutions  as  various 
hypotheses  are  explored.  All  locations,  -ncluding  the  final  network  location,  are  computed  with 
the  LoeSAT  module  described  in  Section  4. 3.2.4. 

The  reasoning  process  is  sketched  in  Figure  4.3.  The  various  steps  arc  described  below. 

Event  Grouping 

Pairs  of  singlc-.station  locations,  one  from  each  array,  arc  candidates  for  grouping  if  their  origin 
times  are  within  six  minutes.  A  pair  i.s  grouped  if  the  location  from  one  array  has  at  least  one 
defining  pha  ;e  consistent  with  a  common  origin  for  at  least  one  defining  phase  from  the 
location  at  the  other  array.  Two  defining  phases  arc  consistent  if  their  arrival  times  fit  a  single 
origin  within  the  area  of  overlap  of  the  2.5*delaz  bounds  on  the  azimuths. 

Check  for  Overlapping  Ellipses 

The  ellipses  from  grouped  single-station  locations  arc  compared  to  determine  if  their  90% 


+  The  initial  implementation  of  "phase  identification"  (Section  4.3.2.3)  docs  not  include  rules  for  iden¬ 
tifying  Rg, 
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Figure  4.3.  The  reasoning  used  fo.  network  processing  is  outlined.  The  output  of  this 
processing  is  indicated  in  the  three  boxes  on  the  right  side  of  the  figure. 


confidence  ellipsoids  (latitude,  longitude,  origin  time)  overlap.  If  they  do,  the  single-array 
locations  are  assumed  to  be  correct  (i.e.,  the  associated  phases  are  assumed  to  be  identified 
correctly),  and  a  network  location  is  computed.  If  they  do  not,  the  next  step  is  initiated. 


Backtrack  &  Revise  to  Seek  Overlapping  Ellipses 

First,  the  location  nearest  its  locating  array  (array  A)  is  assumed  to  be  correct.  The  defining 
phases  from  the  array  B  location  are  then  revised  by  applying  the  rules  listed  below  one-by- 
one  in  the  order  listed. 


Change  Sn  to  Lg.  If  both  Sn  and  Lg  are  already  present,  also  change  the  current 
Lg  to  S. 

Change  Lg  to  Sn.  If  both  Sn  and  Lg  are  already  present,  also  change  the  current 
Sn  to  S. 

Change  Pg  to  Pn.  If  both  Pn  and  Pg  arc  already  present,  also  change  the  current  Pn 
to  P. 

Change  Pn  to  Pg.  If  both  Pn  and  Pg  are  already  present,  also  change  the  current  Pg 
to  P. 


Each  revision  gives  a  new  array  B  location,  and  this  is  tested  to  sec  if  the  new  confidence 
ellipsoid  overlaps  with  that  from  the  array  A  location.  If  they  do,  these  single-array  locations 
arc  assumed  to  be  correct,  and  a  network  location  is  computed.  If  the  array  B  revision  options 
are  exhausted  without  success,  the  original  array  B  solution  is  fixed,  and  the  same  revision 
rules  are  applied  to  the  defining  phases  for  the  array  A  solution.  If  overlapping  confidence 
ellipsoids  are  found,  this  set  of  phase  identities  is  used  for  the  network  location. 

As  currently  implemented,  this  backtracking  is  limited  to  revision  of  one  defining  phase  from 
one  array  and  elimination  of  at  most  one  defining  phase.  There  are  no  rules  that  allow 
changing  undefining  P  or  S  into  a  defining  phase,  or  that  allow  revision  of  defining  phases  at 
both  arrays.  If  these  revision  options  are  exhausted  without  finding  a  pair  of  overlapping 
ellipsoids,  the  processing  moves  to  the  next  step. 


Check  for  Corroborating  Phases 

At  this  step  individual  phases  from  the  other  array  are  sought  to  corroborate  the  remaining 
single-station  locations.  Each  single-station  location  is  considered  in  order,  based  on  origin 
time.  The  90%  confidence  ellipsoid  for  this  location  (the  ’’reference  location")  is  used  to 
compute  the  minimum  and  maximum  arrival  times  for  each  defining  phase  at  the  other  station. 
If  any  phase  at  the  other  station  has  arrival  time  within  this  time  window,  is  of  the  correct  type 
(e.g.,  P  for  Pn  and  Pg),  and  is  not  already  a  defining  phase  for  another  event,  it  is  added  to  the 
reference  location  as  a  defining  phase  from  the  other  array.  If  several  phases  satisfy  these 
criteria,  the  one  with  arrival  time  closest  to  the  center  of  the  time  window  is  chosen. 

There  arc  no  limitations  on  the  number  (up  to  four)  of  corroborating  phases  found  in  this  way, 
but  usually  there  is  only  one.  Occasionally,  both  Pn  and  Pg  arc  found,  and  rarely  both  Sn  and 
Lg  are  found.  'We  would  not  expect  to  find  a  P-type  and  an  S-type  defining  phase  at  this 
stage,  since  the  phases  that  meet  the  conditions  for  corroboration  would  almost  certainly  have 
been  identified  already  during  single-station  processing. 


Backtrack  &  Revise  to  Seek  Corroborating  Phases 

If  the  previous  step  finds  no  corroborating  phases  for  the  original  single-station  location,  that 
reference  location  is  revised  using  the  same  rules  applied  during  backtracking  with  overlapping 
ellipsoids.  The.se  rules  arc  applied  onc-by-onc,  and  the  process  is  terminated  if  one  or  more 
corroborating  phases  arc  found.  The  current  reference  location  and  corroborating  phases  arc 
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assumed  to  provide  the  correct  interpretation,  and  the  network  location  is  computed.  If  all 
revision  options  are  exhausted  without  finding  a  corroborating  phase,  the  original  single-station 
location  is  assumed  to  be  correct. 

Seek  Two-Station.  Two-Phase  Events 

At  this  step  all  remaining  phases  that  have  not  been  associated  with  an  event  are  analyzed  to 
define  events  with  only  one  defining  phase  at  each  array.  First,  phases  from  one  array  are 
paired  with  phases  at  the  other  array  if  their  arrival  times  are  separated  by  less  than  six 
minutes.  These  pairs  are  considered  one-by-one  in  order  of  origin  time.  For  each  pair  the 
array  with  the  earliest  arrival  time  phase  is  chosen  as  the  reference  (array  A).  For  each  of  the 
two  possibilities  (Pn  and  Pg  if  the  array  A  phase  is  P,  Sn  and  Lg  if  it  is  S),  an  origin  time  can 
be  computed  for  any  location  in  the  area  of  overlap  of  the  2.5*delaz  bounds  on  the  azimuths. 
With  this  origin  time  and  the  minimum  and  maximum  epicentral  distance  with  respect  to  the 
other  array  (array  B),  an  arrival  time  window  (T^)  is  defined  for  phases  at  array  B.  When  a 
phase  falls  within  this  window,  a  potential  event  solution  has  been  found.  There  are  four 
possible  phase  identification  pairs,  and  more  than  one  pair  may  satisfy  these  criteria.  When 
this  occurs,  the  ratio  C/D  is  computed  for  each,  using  the  travel-time  of  the  phase  at  array  B. 
In  this  ratio,  C  is  the  travel  time  between  the  estimated  location  and  the  point  at  the  center  .>f 
the  area  of  overlap  of  the  azimuth  bounds,  and  D  is  0.5*T^  plus  the  sum  of  the  deltim  for  the 
two  phases.  The  solution  with  the  smallest  C/D  is  selected.  In  effect  this  selects  the  event 
solution  closest  to  the  center  of  the  area  of  overlap  of  the  azimuth  bounds. 


4.3.4.  Explanation 

One  of  the  defining  attributes  of  an  "expert  system"  is  that  it  provide  an  explanation  of  the 
reasoning  leading  to  its  decisions.  Expert  system  software  techniques  and  languages  (in  this 
case.  Lisp)  facilitate  the  presentation  of  elaborate  and  complete  explanation  of  the  reasoning 
while  all  relevant  data  are  resident  in  the  program  memory.  However,  in  IAS  interesting  events 
happen  at  unpredictable  and  inconvenient  limes.  Thus  a  scenario  in  which  a  seismologist  must 
note  the  occurancc  of  something  interesting  and  ask  the  system  to  pause  while  he  examines  the 
reasoning  is  not  practical.  Instead,  the  choice  is  between  two  fundamentally  different 
approaches:  (1)  obtain  a  complete  explanation  with  typical  expert  system  techniques  by 
rerunning  the  expert  system  I  for  interesting  data  segmenLs;  or  (2)  cache  enough  information  in 
the  DBMS  to  provide  an  adequate  explanation.  The  advantage  of  storing  information  in  a 
DBMS  ’re  obvious;  the  disadvantage  is  that  something  important  may  be  lost  when  forcing  the 
information  into  this  relatively  rigid  format. 

Our  IAS  design  decision  was  to  satisfy  the  requirements  f">r  explanation  exclusively  through 
approach  (2).  ASSESS  has  no  graphical  or  text  displays  beyond  those  used  by  programmers. 
All  displays  of  ASSESS  results  and  reasoning  are  based  on  ASSESS  output  cached  in  the 
DBMS.  Included  in  this  output  is  an  "audit  trail"  stored  in  several  DBMS  tables.  As 
discussed  in  Section  2.4,  this  audit  trail  serves  two  purposes.  One  is  explanation,  and  the 
second  is  to  provide  a  basis  for  performance  validation,  which  is  a  cornerstone  of  the  IAS 
approach  to  knowledge  acquisition  (sec  Section  4.7).  The  design  of  the  audit  trail  is  driven  by 
the  requirements  for  performance  validation,  and  explanation  requirements  arc  secondary. 


t  Since  ii  is  always  possible  to  rerun  the  expert  system  for  any  data  segment  and  to  sec  what  it  is  do¬ 
ing  (with  debugging  tools,  if  nothing  else),  the  choice  is  really  about  how  much  effort  to  devote  to  the 
user  interface  to  make  this  convenient. 
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4J.4.1.  Audit  Trail  Organization 

ASSESS  uses  rule-based  reasoning  to  interpret  the  data  from  SigPro.  The  objective  is  to 
maintain  an  audit  trail  that  provides  a  basis  for  reconstructing  the  decision  process,  so  it  is  not 
necessary  to  record  every  decision.  Rules  or  groups  of  rules  used  to  make  important  decisions 
are  represented  by  "knowledge  sources"  (KS).  These  KS  are  segmented  into  seven  distina 
"KS  classes,"  which  follow  closely  the  reasoning  steps  shown  in  Figure  4.2.  These  seven 
classes  are: 

•  Signal  Processing 

Knowledge  used  to  declare  a  detection. 

•  Initial  Phase  Identification 

Knowledge  used  to  identify  phases  as  P,  S,  T,  or  N  (Section  4.3.2. 1). 

•  Detection  Grouping 

Knowledge  used  to  form  the  "initial  detection  grouping"  (see  Section  4.3.2. 2). 

•  Phase  Association 

Knowledge  used  to  associate  phases  into  event  groups  (Section  4. 3.2. 2). 

•  Final  Phase  Identification 

Kjiowledge  used  to  assign  the  defining  phase  identifiers  Pn,  Pg,  Sn,  Lg,  leading  directly 
to  a  single-array  location  (Section  4. 3.2.3). 

•  Event  Grouping 

Knowledge  used  to  group  pairs  of  single-array  locations  that  potentially  represent  the 
same  event  (Section  4.3.3). 

•  Network  Location 

Knowledge  used  to  form  the  final  network  location  (Section  4.3.3). 

These  seven  classes  contain  a  total  of  40  knowledge  sources.  The  largest  class  is  Final  Phase 
Identification  which  contains  22.  Some  classes  (Signal  Processing,  Detection  Grouping,  Event 
Grouping)  contain  only  one  KS.  The  motivation  for  the  latter  classes  is  not  to  provide 
information  about  decision  process  (it  can  usually  be  inferred),  but  to  provide  an  audit  record 
to  be  invalidated  if  the  analyst  effectively  changes  the  decision  made  by  ASSESS  at  that  stage 
of  the  processing(sce  Section  4.7). 

4_3.4.2.  Audit  Trail  Structure 

The  audit  trail  is  stored  in  the  DBMS  tables  shown  in  Figure  4.4.  ASSESS  writes  to  the  detloc, 
audit  and  audvarbind  tables,  while  kstemplate  and  paramdesc  are  quasi-static  lookup  tables. 
Records  in  the  detloc  table  link  detected  signals  with  event  solutions  (see  Section  3.2).  For 
each  record  in  detloc  there  are  seven  records  in  audit,  one  for  each  KS  class.  Each  of  these 
audit  records  points  to  the  KS  which  was  used  for  the  decision.  Many  KS  use  the  values  of 
parameters,  and  these  values  are  written  to  the  audvarbind  table.  That  is,  there  is  one 
audvarbind  record  for  each  parameter  in  the  KS  referenced  by  each  audit  record.  For  example, 
for  each  detloc  record  ASSESS  writes  7  audit  records  and  perhaps  28  audvarbind  records 
(assuming  an  average  of  4  parameters  per  KS). 

The  audit  table  is  the  key  to  performance  validation,  as  discus.sed  in  Section  4.7.  The  other 
tables  arc  primarily  for  explanation.  The  kstemplate  table  provides  a  text  rendition  of  each  KS. 
Definitions  of  the  parameters  that  appear  in  the  KS  are  stored  in  a  readable  form  in  paramdesc. 
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4  J.4.3.  Retrieving  Explanation 

In  IAS  explanation  is  provided  as  a  menu  option  in  the  Analyst  Review  Station  (ARS) 
described  in  Section  4.6.  For  any  event-detection  pair  (i.e.,  detloc  record)  the  responsible 
knowledge  source  is  obtained  from  audit  for  any  one  of  the  seven  stages  of  the  reasoning 
process.  A  human-readable  version  of  this  knowledge  source  is  retrieved  from  kstemplate,  and 
the  value  of  any  parameters  appearing  in  this  description  is  retrieved  from  paramdesc. 
Definition  of  the  parameters  is  retrieved  from  paramdesc  when  requested. 


4  J.5.  Output  of  ASSESS 

The  output  of  ASSESS  includes  the  following; 

•  An  identification  of  every  phase  detected  by  SigPro  as  T,  N,  P,  S,  Pn,  Pg,  Sn,  or 
Lg. 

•  An  association  of  each  defining  phase  (Pn,  Pg,  Sn,  Lg)  with  an  event  location. 

•  A  location  for  each  event  including  a  confidence  ellipsoid. 

•  An  audit  trail  containing  a  record  of  the  major  decision  made  during  the 
interpretation  process. 


4J.6.  Magnitude  Calculation 

Since  magnitude  calculations  require  an  event  location,  this  process  is  done  after  the  final 
location  is  determined.  That  is,  after  ASSESS  and  any  location  refinement  processing  (see 
Section  4.4)  are  finished.  Also,  if  analyst  review  (Section  4.0)  revises  the  location,  the 
magnitude  calculation  must  also  be  revised.  In  the  Fall,  1989  operation  of  IAS,  the  magnitude 
calculations  were  not  done  as  part  of  the  automated  near  real-time  processing,  but  as  a  post¬ 
process  initiated  after  analyst  review  of  the  data  was  completed. 

The  magnitude  in  the  IAS  bulletins  is  computed  from  the  amplitude  of  Lg.  This  is  the  peak 
amplitude  of  a  filtered  (2-4  Hz)  incoherent  beam  (with  no  steering  delays)  of  the  available 
vertical  channels  in  the  AO,  B,  and  C  rings  in  the  window  between  times  defined  by  group 
velocities  of  3.0  and  3.6  km/sec.  The  distance  correction  converting  this  amplitude  to 
magnitude  is  taken  from  BSth  et  al.  (1976).  This  magnitude  is  computed  for  each  station 
which  has  any  defining  phase  for  the  event  (i.e.,  it  need  not  have  a  delected  and  identified  Lg 
phase).  The  network  magnitude  is  simply  the  mean  of  the  station  magnitudes. 
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4.4.  SCRIPT  MATCHING  AND  ACQUISITION 

The  ASSESS  module  described  in  the  previous  section  uses  general  and  region-specific 
knowledge  expressed  in  rules  to  associate  detections  with  events.  The  travel-times  and  azimuth 
of  these  associated  detections  are  then  inverted  for  a  location  solution  (Section  4.3.2.4). 
Specific  characteristics  of  events  previously  seen  in  the  vicinity  of  the  estimated  location  are 
not  considered  directly  in  this  process,  and  these  can  be  very  important  for  refining  the  location 
or  identifying  the  nature  of  the  event.  This  area-specific  knowledge  is  represented  in  MS  by 
what  are  called  scripts,  and  script  matching  is  the  process  by  which  events  are  compared  with 
these  scripts. 

The  script  concept  was  first  developed  in  artificial  intelligence  research  in  automatic  story 
understanding  (Shanks  and  Abelson,  1977).  Baumgardt(1987)  suggested  that  this  concept 
could  be  applied  in  seismology  by  using  scripts  to  represent  feature  patterns  for  prototypical 
seismic  events  in  a  case-based  reasoning  system  for  event  characterization.  These  seismic 
scripts  would  then  be  matched  against  features  in  the  incoming  data.  An  initial  prototype 
implementing  this  concept  was  developed  and  described  by  Kandt  et  al.  (1987)  and  Baumgardt 
(1987). 

In  IAS  this  concept  is  implemented  in  the  SAS  and  ScriptMatch  modules.  The  implementation 
is  entirely  due  to  the  subcontractor  team  of  Ensco  and  ISX  (formerly  Teknowledge  Federal 
Systems).  TTic  description  presented  here  is  extracted  from  IAS  project  documents  written  by 
Doug  Baumgardt  and  Sam  Carter  of  Ensco  and  Paul  Kegclmeyer  of  ISX. 

The  script  acquisition  system  (SAS)  analyzes  the  detections  from  a  group  of  similar  events  to 
obtain  a  script  that  represents  the  robust  characteristics  distinguishing  this  group  of  events.  In 
script  matching  the  detections  from  an  event  are  compared  with  a  set  of  scripts  to  obtain  a 
measure  of  the  closeness-of-fit  to  each  script.  Simple  rules  are  then  applied  to  determine  the 
confidence  with  which  the  current  event  can  be  said  to  be  another  instance  of  the  group  of 
events  represented  by  the  script.  While  not  yet  fully  implemented,  the  concept  is  for  this  to 
provide  a  basis  for  refining  the  location  by  "joint  epicenter"  or  "master  event"  methods  (e.g., 
Douglas,  1967;  Jordan  and  Sverdrup,  1981).  It  also  provides  information  used  for  event 
identification  (see  Section  4.5)  (e.g.,  the  signals  are  so  similar  to  those  from  previous  events  of 
a  specific  typx:  that  it  is  likely  to  be  another  instance  of  this  type). 

Effective  script  matching  requires  an  adequate  number  of  events  to  form  statistically 
meaningful  scripts  Since  a  significant  period  of  routine  operation  is  is  required  to  acquire 
enough  events,  script  matching  is  incorporated  in  the  first  operational  version  of  IAS  only  for 
concept  demonstration  purposes.  In  this  section  we  describe  this  first  implementation  of  the 
script  matching  concept  in  the  ScriptMatch  and  SAS  software  modules  (Figure  3.1).  Based  on 
experience  accumulated  during  the  initial  operational  period,  we  expect  to  be  able  to  define 
improved  scripts  which  will  become  part  of  the  routine  operation. 


4.4.1.  Script  Acquisition  System  (SAS) 

The  objective  of  SAS  is  to  compute  script  that  represent  distinguishing  patterns  of  features  for 
significant  groups  of  events  (e.g.,  classification  by  specific  location  or  by  event  type).  There  is 
a  very  large  literature  devoted  to  classification  problems  of  this  type."!"  Most  techniques  work 
best  for  large  databases  with  unbiased  sampling  of  the  population  considered.  Seismic  data  are 
difficult  because  they  are  so  biased.  That  is,  there  arc  many  instances  of  some  types  of  events, 

+  Some  examples  include  Duda  and  Han,  1973;  Fisher  and  Langley,  1986;  Quinlan,  1986.  For  a  re¬ 
cent  review  with  many  references,  see  Weiss  and  Kapouleas,  1989. 
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and  few  or  no  instances  of  other  important  types  of  events.  Also,  the  most  robust  classifiers  of 
events  in  different  areas  (phase  azimuths  and  the  inter-phase  time  separation)  provide  a  trivial 
classification  at  this  stage  of  the  processing  (they  have  already  been  used  by  the  rule-based 
location  module).  At  this  stage  the  need  is  for  classification  based  on  more  subtle  features  that 
have  not  yet  been  considered.  Some  candidate  features  are  relative  amplitudes  and  azimuths  of 
defining  phases  (or  even  coda  detections),  frequency  content,  polarization  characteristics,  phase 
velocity  patterns,  etc. 

The  scripts  computed  by  SAS  contain  three  sections: 

•  Header:  Contains  instance  variables  which  describe  information  about  the  seismic  event, 
including  location,  magnitude,  and  standard  deviations  of  these  source  parameters,  textual 
descriptions  of  the  event  (earthquakes,  explosions,  mine  blast),  source  of  the  event 
information,  and  a  list  of  the  orids  (unique  identifiers  of  events  in  the  DBMS)  for  the 
events  which  generated  the  script. 

•  Phase  Description:  TTiis  includes  an  instance  for  each  phase  expected  in  the  script. 
Instance  variables  include  the  phase  name,  station  id,  number  of  occurrences  of  the  phase 
which  were  found  in  the  events  that  generated  the  script,  and  the  prior  probability  of  the 
phase  occurrences.  The  latter  is  computed  by  dividing  the  number  of  phase  occurrences 
by  the  total  number  of  events  used  to  produce  the  script.  Also,  a  list  of  the  arids  (unique 
identifiers  of  detections  in  the  DBMS)  for  the  detections  is  included.  The  lists  of  orids 
and  associated  arids  provides  an  audit  trail  of  the  data  which  produced  the  scripts. 

•  Feature  List:  Contains  a  list  of  features  associated  with  the  phase,  their  mean  values,  the 
observed  standard  deviations  (stdev),  and  their  match  standard  deviations  (mtchdev). 

SAS  has  access  to  all  data  output  by  the  SigPro  and  ASSESS  modules.  In  the  initial 
implementation  the  features  used  to  make  scripts  include  time,  vel,  seaz,  stav,  freq,  Itav, 
STA(i),  and  LTA(i).  The  first  three  are  defined  in  Section  4.3.1,  and  freq  is  the  dominant 
frequency  of  the  detection  determined  during  the  waveform  analysis  described  in  Section 
4.2.3. 1.  In  that  section  we  also  describe  the  computation  of  STA  and  LTA  for  six  standard 
beams,  and  these  are  denoted  by  STA(i)  and  LTA(i),  /=/,.. ,6.  The  Itav  is  the  long-term  average 
for  the  detecting  beam;  i.e.,  the  beam  on  which  stav  is  measured. 

For  the  scripts  the  arrival  times  (time)  are  converted  to  relative  arrival  times  {reltim)  defined 
relative  to  the  time  for  the  earliest  arriving  phase  associated  with  the  event.  The  seven 
amplitudes  are  represented  by  relative  values  (relsnr)  in  decibels.  These  are  computed  from 
the  ratio  of  the  stav  and  STA(i)  of  each  phase  relative  to  the  Itav  and  LTA(i)  for  the  earliest 
arriving  phase  (i.e.,  with  respect  to  the  best  available  measure  of  the  ambient  noise). 

In  the  current  implementation  SAS  requires  that  the  group  of  events  to  be  represented  by  a 
script  be  selected  interactively  by  a  human  analyst.  Each  event  is  represented  by  the  "script 
features"  reltim,  vel,  seaz,  freq,  and  the  seven  relsnr,  as  described  above.  The  SAS  process 
aligns  all  phases  in  each  event  on  the  lime  of  the  first  phase  (i.e.,  reltim  =  0).  A  simple  mean 
of  the  values  of  the  "script  features"  is  then  computed  for  the  defining  phases  (Pn,  Pg,  Sn,  Lg) 
for  each  event  in  the  group.  If  there  are  n  events  in  the  group,  and  a  defining  phase  is  present 
in  only  m  events,  the  averaging  is  done  over  the  these  m  events.  This  is  represented  by  a 
"prior  probability,"  which  is  the  ratio  min.  This  prior  probability  is  used  in  the  script  matcher 
when  calculating  the  overall  confidence  of  a  match.  Along  with  the  mean,  SAS  computes  the 
sample  standard  deviation  for  each  feature  {stdev). 

SAS  computes  scripts  for  events  recorded  by  multiple  arrays  in  the  same  way  except  that  the 
reltim  and  relsnr  are  computed  relative  to  the  first  associated  phase  (usually  Pn  from  the 
nearest  array).  Thus,  a  multiarray  script  looks  much  the  same  as  a  single  array  script  except 
that  there  may  be  multiple  defining  phases  of  the  same  type  with  different  station  names. 
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The  SAS  also  includes  a  set  of  a  priori  estimates  for  the  standard  deviations,  since  the  stdev  are 
often  unrepresentative,  particularly  for  small  samples  of  events.  This  a  priori  error  estimate 
(called  mtchdev)  is  part  of  the  script,  and  so  is  available  for  use  in  the  script  matching  process. 
Each  feature  in  the  script  is  assigned  a  weight  between  0  and  1.  The  default  value  is  1,  but 
the  user  can  interactively  reduce  it  to  reduce  the  importance  of  this  feature  in  subsequent  script 
matching. 


4.4.2.  Script  Matching  (ScriptMatch) 

The  ScriptMatch  module  selects  the  best  matching  scripts  from  a  list  of  candidate  scripts.  In 
most  cases  the  candidate  scripts  are  those  for  locations  within  the  confidence  ellipse  for  the 
event  computed  by  ASSESS.  The  search  can  be  expanded  to  include  scripts  for  locations 
within  some  larger  area  that  is  a  multiple  of  that  confidence  ellipse.  The  hypothesis  formation 
can  be  done  in  two  modes;  forced  and  constrained.  In  the  forced-match  mode  the  phase 
identifications  assigned  by  ASSESS  are  "force  matched"  against  the  same  phases  in  the  script, 
and  the  closest  matching  script  arc  selected.  In  the  constrained-match  mode,  all  associateo 
detections  are  matched  against  scripts  without  regard  to  the  ASSESS  phase  identifications.  In 
this  mode  ScriptMatch  checks  all  possible  P  {yet>6)  and  S  {vel<6)  matches.  Also  calculated 
are  feature,  phase,  and  event  (or  script)  match  confidences. 

Two  kinds  of  features  are  defined  in  the  scripts:  Primary  and  Secondary.  The  Primary  features 
are  the  ones  used  by  ASSESS  to  identify  and  associate  phases  and  include  time  and  seaz.  The 
Secondary  features  include  freq,  vel  and  the  seven  relsnr  described  in  the  previous  section. 
Also,  ScriptMatch  has  the  capability  to  match  amplitudes  measured  in  spectral  bins  (using  the 
spectrum  for  the  phase  output  by  SigPro).  The  spectral  bins  are  identified  in  the  script.  An 
average  rms  amplitude  is  measured  in  these  bins  on  both  signal  and  noise  spectra,  and  these 
spectral  amplitudes  are  converted  to  relsnr  values. 

A  standard  deviation  is  also  assigned  to  each  feature.  This  can  be  stdev,  the  standard  deviation 
of  the  population  used  to  compute  the  script  (appropriate  for  large  populations),  or  it  can  be  an 
assigned  value  called  mtchdev.  When  only  a  single  event  is  used  to  make  the  script,  mtchdev 
is  typically  assigned  as  10%  of  the  feature  value.  For  reltim  a  fixed  value  of  10  seconds  is 
used  in  the  current  implementation. 

An  example  of  output  of  the  ScriptMatch  process  is  shown  in  Figure  4,4.  In  this  case  the 
best-matching  script  is  one  called  "E6."  It  includes  two  phases,  Pn  and  Lg,  at  NORESS.  The 
details  of  the  match  for  the  primary  and  2  secondary  features  for  these  two  phases  are  shown 
in  the  bottom  two  panels.  In  these  two  panels  "Script"  is  the  value  {a,)  of  the  feature  stored  in 
the  script.  "Event"  is  value  (a^)  of  the  feature  for  the  corresponding  phase  in  the  phase  group. 
"Diff  is  the  difference  (og-a^)  between  the  two.  "Dev"  is  he  sample  standard  deviation  (i)  of 
the  feature  (stdev  or  mtchdev).  "Conf  is  one  minus  the  area  under  the  normal  distribution  for 
the  normal  deviate,  z,  represented  as  N(z,a).  TTe  normal  deviate  (z)  is: 

o 

where  a  is  the  standard  deviation  for  the  feature  (stdev  or  mtchdev).  High  confidence  indicates 
that  "Diff  is  small  relative  to  the  o. 

The  ScriptMatch  event  confidence  (65.1%  for  the  ex  '  "<lc  in  the  figure)  is  derived  from  the 
feature  and  phase  confidences.  The  feature  confidence  i.s  the  "Conf  described  above.  In  the 
current  implementation,  the  phase  confidence  is  the  simple  average  of  the  feature  confidences, 
and  the  event  confidence  is  the  simple  average  of  the  phase  confidences.  For  the  latter  each 
phase  confidence  is  weighted  by  the  prior  probabilities  stored  in  the  script,  thus  weighting  this 
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phase  by  ihe  probability  that  it  will  be  observed.  For  the  example  in  Figure  4.5,  the  prior 
probability  is  unity  for  each  phase.  The  "primary  confidence"  listed  for  the  event  is  the  simple 
average  of  the  "conf  for  the  primary  features  for  the  two  phases,  and  the  "secondary 
confidence"  is  the  simple  average  of  the  "conf'  for  secondary  features. 
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icrlpt  Hatches  foe  «v«nt  3Sll 

Matchld  2S:  Hatched  with  overall  confidence  6S.7% 


I 


Hatched  with  primary  confidence  88.9% 
Hatched  with  secondary  confidence  47.0% 


[Phase^  Hatches  for  E6  script  -  Hatchid:  2S | 

Latitude  S9.3 
Longitude  27.6 

I  dent i f lea t ion:  CstonlaKineBlast(C6 ) 

jprij  Matched  6041(IIOR)  with  confidence  70.7% 

I 

j  [l.gj  Katv.l»ed  6044(NOR)  with  confidence  60.6% 


Phase  Hatch  Explanation 

Pn  ( HOR  ) 

For  matchld  25 

Matcl>ed  arrival  6041  (confidence  70.7  %)  , derived  from: 


Feature 

Scr Ipt 

Event 

Dlff 

Dev 

Conf 

TIME 

0.00 

2.36 

2.36 

10.00 

0.81 

AXIMUTH 

95.60 

95.01 

-0.59 

25.50 

0.98 

FREQUENCY 

3.80 

5.45 

1.65 

2.00 

0.41 

VELOCITY 

11.00 

8.85 

-2.15 

4.40 

0.63 

Phase  Hatch  Explanation 

Lq  (HOP  ) 

For  Mtchld  25 

Hatched  arrival  6044  (confidence  60.6  %)  , derived  from: 


Feature 

Scr ipt 

Event 

oirr 

Dev 

Conf 

TIME 

135,25 

132.89 

-2.36 

10.00 

0.81 

J17IMXrTH 

99.50 

100.09 

0.59 

9.00 

0.95 

REL-SHR 

13.10 

10.74 

-2.36 

4.00 

0.55 

FREQUENCY 

2.80 

1.30 

-1.50 

0.  10 

0.00 

VELOCITY 

4.00 

4.22 

0,22 

0.60 

0.71 

Figure  4.5.  Tlic  otilpul  (if  lltic  ScriptMatch  process  includes  three  different  displays.  nie 
Iksi  niaichinp  scripts  (up  to  three)  arc  li.slcd  in  the  top  panel  with  the  confidence  estimates 
I  he  second  panel  shows  the  confidence  of  llic  match  for  each  phase  in  the  script,  and  the 
bottom  two  panels  show  die  match  for  several  features  for  each  phase. 
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4^.  EVENT  IDENTIFICATION 

In  the  initial  implementation  of  MS.  the  event  identification  module  (Eventid)  is  a  post¬ 
processor  started  manually  (or  on  a  schedule)  for  events  meeting  some  preset  criteria  (e.g.,  all 
events  above  magnitude  2  within  the  Soviet  Union).  Events  are  identified  within  five  classes; 


EX 

Almost  certainly  an  industrial  explosion 

UNK-EX 

Explosion-like 

UNK 

Unidentified 

UNK-EQ 

Earthquake-like 

EQ 

Almost  certainly  an  earthquake 

This  identification  is  based  on  the  event  location  and  results  from  three  event  characterization 
processes:  ScriptMatch,  MERSY,  and  Sratio.  The  script  matching  was  described  in  Section 
4.4.  The  MERSY  (Multiple-Event  Recognition  System)  process  seeks  evidence  of  "ripple- 
firing"  which  is  uniquely  characteristic  of  industrial  explosions.  The  Sratio  process  e.stimatcs 
S/P  spectral  ratios,  which  can  be  uniquely  characteristic  of  earthquakes.  In  this  section  we 
describe  the  implementation  of  the  latter  two  processes.  We  then  describe  how  the  event 
characterization  information  is  fused  to  obtain  the  overall  event  identification. 


4.5.1.  Multiple-Event  Recognition  System  (MERSY) 

The  MERSY  module  was  developed  by  Ensco,  Inc.,  under  a  subcontract  to  SAIC.  The 
technical  basis  is  presented  by  Baumgardt  and  Ziegler  (1988).  A  functional  description  of  the 
program,  including  examples,  appears  in  Baumgardt  and  Ziegler  (1989).  The  description  here 
is  is  an  edited  version  of  material  in  that  report. 

The  input  to  MERSY  includes  the  output  of  ASSESS  (Section  4.3.5)  and  the  output  of  SigPro 
(Section  4.2.4),  most  notably  the  spectrum  of  every  detected  signal  and  a  preceding  noise 
segment  which  is  used  for  computing  the  cepstrum  for  that  signal.  MERSY  then  computes  two 
kinds  of  cepstra  and  seeks  cepstral  peaks  that  persist  at  the  same  quefrency  for  all  detected 
phases.  Rule-based  reasoning  is  then  applied  to  characterize  the  strength  of  the  evidence  that 
the  event  includes  closely-spaced  (in  time)  multiple  arrivals  characteristic  of  a  ripple-fired 
industrial  explosion.! 

Figure  4.6  shows  the  data  flow  within  the  MERSY  and  the  major  subprocesses.  Two  cepstra 
are  computed,  one  (FFTCEPST)  by  a  straightforward  Fourier  transform  of  the  log  spectra,  and 
the  .second  (MAXENT)  by  a  maximum  entropy  method.  FFTCEPST  reads  the  spectra  and 
computes  the  Fourier  cepstra  as  described  by  Baumgardt  and  Ziegler  (1988).  As  noted  by  these 
authors,  truncation  of  the  specU’a  at  Nyquist  can  produce  distorted  and  false  modulation  peaks, 
particularly  if  the  truncation  occurs  in  the  middle  of  one  of  the  spectral  modulation  cycles. 
The  maximum  entropy  method  extrapolates  the  spectrum  to  frequencies  beyond  Nyquist  using 
a  predictive  filter  in  the  frequency  domain,  and  so  should  eliminate  the.se  spurious  peaks  and 
prv'duce  much  sharper  main  peaks. 

Tl:cse  two  cepstra  are  computed  for  all  the  phases  associated  with  the  event.  If  only  one  array 
has  phases  associated  with  the  event  the  peaks  and  cepstral  statistics  are  extracted  from  the 


+  Baumgardt  and  Ziegler  (1989)  suggest  that  underwater  explosions  have  similar  cepstral  characteris¬ 
tics,  but  more  data  are  needed  to  increase  confidence  in  this  conclusion. 
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CPSTAK 


Fi^ur‘’  4.6.  The  data  flow  among  the  major  subproccsses  of  MERSY  is  shown.  The  associated 
phases  at  each  arrray  follow  the  path  indicated  by  solid  lines.  When  there  are  data  from  more 
than  one  array,  the  ii’dividual  phase  spectra  arc  stacked,  and  path  indicated  by  dashed  lines  is 
followed  instead. 


(CPSTAK),  and  FNDPKS,  CSTATS,  and  PKOUNT  subproccsscs  arc  applied  to  these  stacked 
cepstra.  The  final  process  (DECIDE)  analyzes  the  pattern  of  ccpstral  peaks  and  their 
frequencies  to  determine  whether  the  event  is  a  multiple  event  and  the  confidence  in  that 
decision.  For  apparent  multiple  events  the  delay  timc(s)  and  number  of  events  arc  estimated. 
These  subprocesses  are  described  in  more  detail  in  subsequent  subsections. 

4.5.1. 1.  Fourier  Cepstra  (FFTCEPST) 

This  subprocess  reads  the  Fourier  cepstra  computed  by  SigPro  for  each  associated  phase  and 
computes  the  cepstra  as  follows.  The  instrument  respon.se  is  removed  by  spectral  division,  and 
the  log-rms  signal-to-noise  ratio  is  computed  (convened  to  DB  and  called  snrdh).  The 
logarithm  of  each  spectral  density  is  then  computed  to  whiten  the  spectrum.  The  quadratic 
trend  is  removed  from  a  low  frequency  cutoff  of  1.875  Hz  to  Nyquist  (20  Hz).  This  quadratic 
trend  removal  eliminates  false  cepstral  peaks  due  to  the  high  frequency  rolloff  of  the  spectrum. 
The  low  frequency  cutoff  suppresses  the  false  ccnstral  peaks  due  to  the  instrument  rcspon.se 
removal.  This  whitened  log-amplitude  spectrum  is  u.scd  for  both  the  Fourier  ccp.struin  and  the 
maximum-entropy  cepstrum  de.scribcd  in  the  next  sub.scction.  The  Fourier  cepstrum  is  the  real 
part  of  an  FFT  of  the  log-amplitude  spectrum  after  reflection  about  the  Nyquist  frequency. 

4.5. 1.2.  Maximum  Entropy  Cepstra  (MXENT) 

This  subproccss  computes  a  cepstrum  by  treating  the  amplitude  spectrum  as  a  time-series  using 
the  Burg  (1967)  maximum-entropy  power  .spectrum  method  implemented  with  the  algorithm 
described  by  Anderson  (1974).  The  algorithm  requires  selection  of  the  number  m  of 
coefficients  to  be  included  in  the  predictive  filter  for  n  frequency  points.  This  m  depends 
on  the  complexity  of  the  cepstrum,  which  is  estimated  from  the  logarithm  of  the  Fourier 
ccpstral  variance,  Icvar  (the  calculation  of  variance  is  described  in  Section  4. 5. 1.4).  The 
following  rules  arc  used: 


Icvar  <  —4.7  — »  m  =  60 
Icvar  >  -4.7  and  Icvar  <  -4.5  — >  m  =  80 
Icvar  >  —4.5  and  Icvar  <  —4.3  — »  m  =  90 
Icvar  >  -4.3  m  =  1(X) 


4J.1.3.  Cepstral  Peak  Analysis  (FNDPKS) 


This  subproccss  scans  cepstra  to  find  peaks.  Each  point  where  the  slope  changes  sign  from 
positive  to  negative  ipk)  is  a  possible  peak.  The  nearest  points  on  cither  side  ol  pk  where  the 
slope  changes  sign  from  negative  to  positive  are  found  (tr]  and  ir2).  Using  the  maximum 
value  in  the  cepstrum  (maxcep),  a  pk  is  declared  a  peak  i*' 


pk 


Ur2-lr\\ 


0.2  nuLxeep 
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4^. 1.4.  Spectral/Cepstral  Statistics  (CSTATS) 

This  subprocess  computes  the  variance,  skewness,  and  kurtosis  of  the  spectra  and  cepsU'a.t  The 
variance  is  a  measure  of  the  spectral  or  cepstral  "width"  or  "variability"  around  the  mean  value. 
If  Xj  represents  the  yth  spectral  or  cepstral  value  and  x  the  mean  value,  then  the  variance  or 
second  moment  is: 

Varixi . Xfi)  = 

where  N  is  the  number  of  points  in  the  spectrum  or  cepstrum. 

The  skewness  characterizes  the  degree  of  asymmetry  of  a  function  about  its  mean  value.  It  is 
represented  as  the  third  moment  expressed  as 

1 

Sk£w{x\ . Xu)  =  —  X 1  • 

^  ^iL  o 

where  a  =  a(xi  ■  ■  ■  xJ  is  the  standard  deviation  of  the  spectral  or  cepstral  distribution.  An 
estimate  of  the  standard  deviation  is 

<3{x\ . Xu)  =  'JVarixi  ■  ■  ■  X/„). 


The  kurtosis  gives  a  measure  of  the  "pcakedne.ss"  or  "flamcs.s"  of  'he  spectrum  or  cepstrum 
relative  to  a  normal  distribution  function.  This  feature,  also  known  as  the  fourth  moment,  is 
expressed  as 


Kurt{x\ 


•%)  - 


-  3. 


The  Kurt  is  zero  when  the  spectrum  or  cepstrum  is  normally  distributed. 


4.5.I.5.  Peak  Counting  (PKOUNT) 

This  subprocess  counts  significant  peaks  that  arc  consistent  in  the  sense  that  they  occur  at  the 
within  one  qucfrency  bin  in  two  or  more  cepstra  within  the  group  under  consideration.  For 
data  from  one  array  cepstra  for  all  associated  phases  arc  examined.  When  the  event  has  data 
from  both  arrays,  the  stacked  spectra  from  each  arc  examined.  Peaks  arc  considered  to  be 
significant  if  they  have  a  high  amplitude  and  are  not  present  in  the  noise  cepstrum  for  the  noise 
segment  prior  to  the  earliest  phase  associated  with  the  event  (the  best  available  estimate  of  the 
ambient  noise).  If  pks,  and  pkn,  are  the  signal  and  noi.se  peaks,  for  qucfrency  bin  i,  pks,  is 
significant  if 

pks,  >th,  and  (pkn,  <  th„  or  pLs,  >  3* pkn,  ), 

The  lack  of  a  noise  peak  in  the  ith  cepstral  bin  satisfies  the  condition  pkn,  <  th„.  For  Fourier 
cepstra,  th,  -  th„  =  0.032,  and  for  maximum  entropy  cepstra,  th^  =  th„  =  .(K)I. 


+  While  all  three  of  ifiese  sLatislic.s  are  computed  and  archivcil  in  the  DHM.S,  onU  variance  is  used  in 
subsequent  steps  in  the  current  implementation  of  MERSY. 
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4J.1.6.  Source  Multiplicity  Determination  (DECIDE) 

This  subprocess  applies  a  set  of  rules  to  the  logarithm  of  the  cepstral  variance  (Icvar)  of  the 
last  phase,  the  number  of  Fourier  cepstral  peaks  («//>),  and  the  number  of  maximum-entropy 
cepstral  peaks  (nmep)  to  provide  an  independent  classification  of  the  event  as  a  likely  mine  or 
underwater  explosion  (exp)  or  a  likely  earthquakes  (equ).  The  rules  are: 

IF  nfp  >  0  and  Icvar  >  Icvarth  exp\ 

IF  nfp  >0  and  Icvar  <  Icvarth  and  nmep  =  0  — >  eqw, 

IF  nfp  =  0  and  Icvar  >  Icvarth  and  nmep  >  0  — >  cxp\ 

IF  nfp  =  0  and  Icvar  <  Icvarth  — >  eqw, 

IF  nfp  >  0  and  Icvar  <  Icvarth  and  nmep  >  0  -)  exp\ 

IF  nfp=  0  and  Icvar  >  Icvarth  and  nmep  =  0  — >  equ. 

The  log  cepstral  variance  threshold,  Ivarth,  is  set  to  -4.5. 

The  indep)endent  classification  provided  by  the  DECIDE  subprocess  is  not  used  in  MS. 
Instead,  the  event  characteristics  found  by  MERSY  are  used  in  the  Eventid  process  described  in 
Section  4.5.3. 


4,S.1.7.  Event  Characteristics 


The  MERSY  output  used  by  Eventid  includes  the  snrdb  computed  by  FFTCEPST,  the  logarithm 
of  the  Fourier  cepstral  variance  (Icvar)  computed  by  CSTATS,  and  kurtosis  of  the  Fourier 
cepstrum  (ckur)  computed  by  CSTATS.  Another  important  ailribuie  writen  by  MERSY  is  the 
peak  type,  ptyp,  which  is  defined  to  be: 


FC-ARY 

MC-ARY 

FC-PHS 

MC-PHS 

FC-NOl 

MC-NOl 


If  there  are  consistent  peaks  in  the  Fourier  cepstra  across  two  or  more  arrays. 

If  there  are  consistent  peaks  in  the  maximum  entropy  cepstra  across  two  or  mote 
arrays. 

If  there  are  consistent  peaks  in  the  Fourier  cepstra  across  two  or  more  phases  for 
one  array. 

If  there  are  consistent  peaks  in  the  maximum  entropy  cepstra  across  two  or  more 
phases  for  one  array. 

If  there  are  consistent  noise  peaks  in  the  Fourier  cepstra 

If  there  are  consistent  noise  peaks  in  the  maximum  entropy  cepstra. 
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4J.2.  S/P  Spectral  Ratio  {Sratio) 

The  Sratio  module  computes  the  ratio  of  the  apparent  source  excitation  of  Lg  and  Pn  phases 
using  the  path  corrections  of  Sereno  et  al.  (1988)  applied  to  Pn  and  Lg  spectra.  These  path- 
corrected  spectra  are  inverted  for  the  long-period  source  level  and  comer  frequency  (assuming 
a  source  model  with  frequency-squared  decay  above  the  comer  frequency).  The  ratio  of  the  Lg 
and  Pn  source  levels  is  computed  for  each  station  and  averaged  across  the  network.  This 
average  ratio  is  used  to  identify  the  event  by  comparing  to  the  source  excitation  ratios  for 
previous  events  of  known  source  type.  This  method  is  described  in  more  detail  in  the 
following  subsections. 

4J.2.1.  Computation  of  S/P  Source  Level 

The  input  to  Sratio  includes  the  output  of  ASSESS  (Section  4.3.5)  and  the  spectra  computed  by 
SigPro  (Section  4.2.4).  The  Pn  and  Lg  SNR  spectra  arc  computed  using  the  pte-Pn  noise 
spectmm,  and  a  3-Hz  running  mean  filter  is  applied  to  these  SNR  amplitude  spectra.  The  path 
corrections  are  applied  to  a  frequency  band  over  which  the  smoothed  SNR  spectrum  is  >  1.5, 
but  no  greater  than  the  band  used  to  determine  the  path  corrections  (1-15  Hz  for  Pn  and  1-7 
Hz  for  Lg).  These  smoothed,  band-limited  spectra  arc  corrected  for  the  instrument  respon.se 
and  converted  to  physical  units  (nm-s). 

The  Pn  and  Lg  path  corrections  of  Sereno  et  al.  (1988)  include  geometric  spreading  and  a  Q- 
operator  determined  by  inverting  spectra  computed  for  fixed  5-s  time  windows  (i.e.,  the  SigPro 
spectra).  The  path-corrected  spectra,  5(/),  arc  expressed  in  terms  of  the  instrument-corrected 
amplitude  spectra,  Aif),  as; 


Sif)  =  A(f)r^ 


where  tq  is  the  transition  distance  from  spherical  spreading  to  spreading  rate  m,  r  is  epiccniral 
distance,  t  is  travel  time,  and  Q(f)  has  a  power-law  frequency  dependence  given  by  Qo/’'-  The 
path  parameters  for  Lg  arc;  tq  =  1(X),  m  =  0.5  (cylindrical  spreading),  Qq  =  350,  and  r\  =  0.41. 
The  path  parameters  for  Pn  are;  r^  =  \,  m  =  ].3,  Qo  =  300,  and  =  0.49. 

The  source  is  assumed  to  have  frequency-squared  decay  above  the  comer  frequency,  and  the 
path-corrected  spectra  arc  inverted  for  the  long-px:riod  level  (5o)  and  the  comer  frequency  (fj 
using  iterative  damped  least  squares.  The  data  variance  (the  variance  of  the  fit  of  the  source 
model  to  the  path-corrected  spectra)  and  the  variance  of  log  5o  (parameter  variance)  arc 
computed. 

An  example  of  the  path  corrections  and  source  parameter  inversion  is  shown  in  Figure  4.7. 
This  figure  shows  the  spectra  recorded  at  NORESS  from  a  mine  blast  in  Estonia  (epicentral 
distance  is  930  km)  and  the  same  spectra  after  path  correction  over  the  frequency  band  u.sed  to 
determine  the  NORESS  path  corrections.  The  derived  Pn  and  Lg  source  spectra  arc 
supcrimpo.sed  on  the  path-corrected  spectra,  and  the  long-period  levels  arc  28.3  for  Pn  and  19.9 
for  Lg.  The  comer  frequency  (estimated  from  Pn)  is  114  Hz.  Tlic  NORESS  Lg/Pn  source 
excitation  ratio  is  0.7  for  this  event. 


4,5.2.2.  Earthquake  Classification  with  Sratio 

The  ratio  ScfLg)/SQ(Pn)  is  computed  for  each  station.  The  neiwork-average  ratio  is  calculated 
from  the  individual  ratios  at  each  station  v/cighted  by  the  standard  deviation  of  the  log  So 
estimate.  Event  classitication  is  ba.scd  on  compari.son  of  this  ratio  with  s.ilucs  122  events  with 
known  classification  (Sereno  et  al.,  1988).  In  Figure  4.8  the  Lg/Pn  source  excitation  ratios 
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2.7  Mine  Blast,  930  km  from  NORESS 
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Fif’ure  4.7 .  Example  of  observed  and  path -corrected  spectra  for  an  Mi  2.1 .  mine  blast 
in  Estonia  recorded  at  Nf)RESS.  The  path-corrected  spectra  arc  plotted  over  the  fre¬ 
quency  band  used  to  dctcimine  the  NORESS  path  corrections  (Screno  et  al.,  198^). 
The  derived  Pn  and  .source  spectra  arc  superimposed  on  ‘he  path  corrected  spectra. 
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Figure  4.8.  LgfPn  long-period  source  excitation  ratios  from  132  events  with  known 
classification.  Explosions  are  plotted  as  asterisks  and  earthquakes  as  open  circles.  The 
mean  and  standard  deviation  of  the  explosion  ratio  are  indicated  by  horizontal  lines. 
The  earthquake  rating  is  plotted  in  the  right  panel  as  a  function  of  Lg/Pn  source  excita¬ 
tion  ratio. 
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from  these  events  are  shown  with  explosions  plotted  as  asterisks  and  earthquakes  as  open 
circles.  Qearly,  a  low  value  of  this  ratio  is  inconclusive,  whereas  high  values  indicate  the 
event  is  probably  an  earthquake. 

An  earthquake-classification  rating  is  computed  for  a  new  event  as  indicated  at  the  right  in 
Figure  4.7.  We  assume  that  the  LgfPn  source  excitation  ratio  for  the  71  explosions  is  normally 
distributed.  As  shown  in  Figure  4.7,  the  mean  value  is  0.86,  and  the  standard  deviation  is 
0.65.  For  source  ratios  less  than  or  equal  to  the  mean  value  for  the  explosion  data  set,  the 
earthquake -classification  rating  is  set  to  zero,  indicating  an  inconclusive  classification.  Above 
the  mean  the  earthquake-classification  rating  is  computed  from  the  normal  distribution  over  the 
range  from  0  to  10,  with  10  indicating  the  highest  probability  that  the  event  is  an  earthquake. 

4.5.3.  Information  Fusion  to  Identify  Events 

Event  identification  (classification)  is  done  in  the  Eventld  process.  In  the  current  IAS 
implementation  this  process  includes  a  rule-based  fusion  of  information  from: 

•  Location 

•  Script  matching  (from  ScriptMatch,  Section  4.4) 

•  Evidence  of  ripple-firing  (from  MERSY,  Section  4.5.1) 

•  S/P  spectral  ratios  (from  Sratio,  Section  4.5.2) 

Each  provides  an  independent  classification  into  one  of  the  five  classes  listed  at  the  beginning 
of  Section  4.5  (EX,  UNK-EX,  UNK,  UNK-EQ,  EQ).  These  independent  classifications  arc 
then  combined  by  a  weighted  voting  scheme  to  obtain  an  overall  event  classification.! 

The  event  characteristics  used  for  the  classification  include; 

SIS2JS3  The  three  scripts  (in  order)  with  highest  confidence  of  match. 

C!,C2.C3  The  combined  primary  and  secondary  confidences  for  the  three  highest  confidence 
scripts. 

P(cls)  The  proportion  of  the  three  matching  scripts  that  in  a  particular  class  (els).  For 
example,  if  2  arc  from  mines  (mn),  and  1  is  from  an  underwater  explosion  (uwc), 
P(mn)  ~  0.66  and  P(uwe)  =  0.33.  Other  classes  include  nuclear  explosions  {nuc) 
and  earthquakes  (eq). 

erat  The  "earthquake  rating"  determined  from  S^{Lg)ISo(Pn)  and  defined  in  Figure  4.8 
(Section  4.^  2.2). 

Also  used  arc  the  ptyp,  snrdb,  evar,  and  ckur  output  by  MERSY  (Section  4. 5. 1.7).  The 
classification  is  quantified  by  the  following; 

conf  Indicates  the  confidence  in  the  classification  by  one  of  the  four  independent 
methods. 

wt  Indicates  die  the  weighting  applied  to  this  particular  confidence  when  fusing  the 

classification  from  the  four  methods  to  obtain  an  overall  event  classification. 


+  The  concept,  the  rules  for  MERSY  and  ScriptMatch,  and  the  'veighted  voting  scheme  arc  due  to 
Doug  Baumgardt,  Ensco,  Corp  The  rules  for  Sratio  arc  due  to  Tom  Sereno,  SAIC. 
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4J.3.1.  Event  Classification  by  Independent  Methods 

The  rules  used  to  classify  events  by  the  four  independent  methods  arc  as  follows: 

Location 

EQ  with  conf  =  0.9  and  wt  =  0.8 

If  the  area  enclosed  by  the  confidence  ellipse  is  in  the  deep  ocean  (beyond  the 
continental  shell) 

UNK-EQ  with  conf  =  0.7  and  wt  =  0.8 

If  the  area  enclosed  by  the  confidence  ellipse  is  offshore,  but  the  location  is  on  the 
continental  shelf 

UNK-EX  with  conf  =  0.25  and  wt  -  0.9 

If  max[Ci]  >  0.5  and  P(mn)  =  1.0 

UNK  with  conf  =  0.0 

If  none  of  the  other  rules  for  identification  by  location  arc  satisfied. 


Script  Maichinc 


EQ  with  conf  -  0.9  and  wt  =  0.8 

If  P(eq)  =  1.0  and  max[Cl ,C2,C3\  >  0.8  or  SI  represents  canhquakes  with  Cl  > 
0.9  and  P(eq}  <  1 .0 

UNK-EQ  with  conf  =  0.75  and  wt  =  0.8 

If  P(eq}  =  I.O  and  0.5  <  max[Cl ,C2,C3]  <  0.8  or  SI  represents  earthquakes  with 
0.8  <  Cl  <  0.9  and  P(eq)  <1.0 

UNK-EQ  with  conf=  0.25  and  wt  =  0.8 

If  P(eq)  =  1.0  and  max[C7,C2,CJl  <  0.5  or  SI  represents  mining  explosions  with 
Cl  <  0.6  and  P(eq)  <1.0 

UNK-EX  with  conf  =  0.25  and  wt  =  0.8 

If  P(mn)  =  1.0  and  max[Cl  ,C2,C3\  <  0.5  or  SI  represents  els  -  mn,  nuc,  or  uwe 
with  Cl  <  0.6 

UNK-EX  with  conf  =  0.5  and  wt  =  0.8 

If  P(mn)  =  1.0  and  0.5  <  maxlCl ,C2,C3]  <  0.8  or  SI  represents  els  =  mn,  nuc.  or 
uwe  with  0.6  <  Cl  <  0.9,  and  P(mn)  <  1.0 

EX  with  conf  ~  0.9  and  wt  =  0.85 

If  P(mn)  =  1.0  and  maxlC/,C2,CJl  >  0.8  or  SI  rcprc.scnts  els  =  mn,  nuc.  or  uwe 
with  Cl  >  0.9,  and  P(mn)  <  1.0 

UNK  with  conf  =  0.0 

If  none  of  the  other  rules  for  identification  by  script  matching  arc  satisfied. 


UNK-EX  with  conf  =  0.25  and  wt  =  0.75 

If  ckur  >  11.69  *  evar  +  38  and  ckur  <  30  for  any  of  the  stacked  single  array  or 
multiple  array  cepstra  which  have  .snrdb  <1.0 

UNK-EX  with  conf  -  0.5  and  wt  =  0.75 

If  ckur  >  11.69  *  evar  +  38  and  ckur  >  30  for  any  of  the  slacked  single  array  or 
multiple  array  cepstra  which  have  .snrdb  <1.0 
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UNK-EX  with  conf  =  0.7  and  wt  =  0.75 

If  ckur  >  11.69  *  cvar  +  38  and  ckur  <  30  for  any  of  the  stacked  single  array  or 
multiple  array  cepstra  which  have  snrdb  >1.0 

EX  with  conf  =  0.9  and  wt  =  0.9 

If  ckur  >  11.69  *  cvar  +  38  and  ckur  >  30  for  any  of  the  stacked  single  array  or 
multiple  array  cepstra  which  have  snrdb  >1.0 

EX  with  conf  =  0.9  and  wt  =  0.95 

If  two  of  the  following  conditions  are  satisfied  for  any  of  the  stacked  single  array  or 
multiple  array  cepstra:  ptyp  =  FC-PMS,  ptyp  =  MC-PHS,  ckur  >  11.69  *  cvar  +  38 

EX  with  conf  =  0.95  and  wt  =  0.95 

If  two  of  the  following  conditions  are  satisfied  for  any  of  the  stacked  single  array  or 
multiple  array  cepstra:  ptyp  =  FC-ARY,  ptyp  =  MC-ARY,  ckur  >  1 1.69  *  cvar  +  38 

UNK  with  conf  =  0.0 

If  none  of  the  other  rules  for  identification  by  ccpstral  characteristics  arc  satisfied. 

S  ratio 

EQ  with  conf  =  0.9  and  wt  =  0.9 

If  erat  >  8 

UNK-EQ  with  conf  =  erat/10  and  wt  =  0.8 
If  2  <  erat  <  8 

UNK  with  conf  =  0.0 

If  erat  <  2 

4  J.3.2.  Overall  Event  Classification 

A  simple  weighted  voting  scheme  is  used  to  combine  the  four  independent  classificaiicro  to 
obtain  an  overall  event  classification.  The  four  independent  classifications  arc  represented  by 
conf(i)  and  wt(i),  with  j=l^,3,4.  When  the  classification  is  EX,  UNK-EX,  or  UNK, 

confii)  =  conf. 

When  the  classification  is  EQ  or  UNK-EQ. 

confii)  =  -corf. 

The  overall  classification  is  determined  from 

4 

cest  =  Jj:onJli)  *  wt{i) 

t=\ 


The  values  of  conf(i)*wt(i)  that 
tabulated  below: 

occur  for  the  rules 

u.scd  in  the  current 

implementation  arc 

Location 

ScriptMatch 

MERSY 

S  ratio 

EQ 

-0.72 

-0.72 

0 

-0.81 

UNK-EQ 

-0.52 

-0.2,  -0.6 

0 

-0.64  ...  -0.16 

UNK 

0 

0 

0 

0 

UNK-EX 

0.23 

0.2,  0.4 

0.19  ..  0.53 

EX 

0 

0.77 

0.81  ..  0.90 

0 
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Events  are  identified  by  summing  the  approprite  values  to  compute  cest,  then  applying  the 
following  rules: 

EQ  with  conf  =  -cestfl.25 

If  cest  <  -2.0 

UNK-EQ  with  conf  -  -cest/l.lS 
If  -2.0  <  cest  <  -0.6 

UNK-EX  with  conf=  cestn.25 
If  0.6  <  cest  <  1J5 

EX  with  conf  =  cest/2.25 

If  cest  >  JJ5 

UNK  with  conf  =  -cest/2.25 

If  -0.6  <  cest  <  0.6 

With  these  rules,  Sratio  has  no  role  in  identifying  an  explosion,  and  MERSY  has  no  role  in 
identifying  an  earthquake.  The  conditions  for  identifying  an  event  as  an  explosion  (EX) 
include; 

•  MERSY  =  EX,  ScriptMatch  =  EX  ,  Location  =  UNK-EX 

•  MERSY  =  EX,  ScriptMatch  =  EX  ,  Location  =  UNK 

Similarly,  the  conditions  for  identifying  an  event  as  an  earthquake  (EQ)  are; 

•  Sratio  =  EX,  ScriptMatch  =  EX  ,  Location  =  EX 

•  Sratio  =EX,  ScriptMatch  =  EX  ,  Location  =  UNK-EX 

•  Sratio  =  EX,  ScriptMatch  =  UNK-EX,  Location  =  EX 

Other  combinations  classify  events  as  UNK-EX.  UNK-EQ,  and  UNK,  with  the  attached  conf 
(ranging  from  minimum  of  -1.0  for  class  EQ  to  a  maximum  of  0.84  for  class  EX)  providing  a 
rough  indication  of  the  strength  of  the  evidence  that  an  event  is  an  explosion  or  earthquake. 

These  event  classification  rules  are  an  od  hoc  representation  of  current  knowledge  for 
identifying  events  with  regional  array  data.  Much  more  empirical  work  is  required  to  develop 
and  test  rules  that  provide  truly  effective  event  classification.  Also  needed  is  a  more  rigorous 
seismological  and  statistical  basis  for  the  rules  in  each  method  and  the  fu.sion  of  evidence  from 
them.  The  IAS  provides  for  the  first  time  an  operational  system  capable  of  collecting  the  data 
for  a  thorough  investigation  of  these  important  issues. 
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4.6.  ANALYST  REVIEW 


The  important  processes  for  analyst  review  (Figure  3.1)  include  ARS  (Analyst  Review  Station), 
map,  and  IVAS.  ARS  provides  the  interactive  di.splay  and  editing  tools  to  review,  explain 
(Section  4.3.4),  and  correct  the  solutions.  It  is  tightly  integrated  with  the  map  process  for 
geographical  displays.  IVAS  is  a  special-purpose  system  (from  International  Imaging  Systems, 
Inc.)  for  display  and  manipulation  of  imagery.  In  IAS  the  IVAS  is  used  primarily  for  satellite 
images  from  SPOT  Image  Corporation,  and  this  capability  is  also  integrated  with  ARS. 

In  this  section  the  emphasis  is  on  ARS  interaction  with  the  DBMS,  since  analyst  validation  of 
ASSESS  solutions  is  an  important  part  of  knowledge  acquisition  (Section  4.7).  The  user- 
interface  and  functions  of  the  graphics-intensive  interactive  processes  are  described  in  the 
user-documer'.ation,  t  particularly  the  Analyst  Review  Station  Tutorial,  the  Analyst  Review 
Station  Reference  Manual,  and  the  Map  Tutorial.  The  IVAS  has  extensive  documentation 
from  the  vendor  describing  its  functions,  and  examples  of  the  imagery  used  in  IAS  arc  given  in 
Fox  (1989). 

A  typical  screen  viewed  by  the  analy.st  is  shown  in  Figure  4.9.  A  particular  event  has  been 
selected  for  review  and  correction.  In  this  example  ASSESS  has  made  a  minor  error  in  the 
identification  of  the  Sn  arrival  at  NORESS.  Using  ARS  tools,  the  analyst  can  interchange  the 
identity  of  the  two  closely-spaced  NORESS  S  phases,  since  the  second  appears  to  be  at  the 
actual  Sn  arrival  time.  Since  the  new  Sn  arrival  time  is  clo.se  to  the  expected  Sn  arrival  time 
for  original  location  solution,  we  know  that  this  change  will  not  move  the  location  very  much. 

The  analyst  usually  expands  the  trace  to  examine  the  onset  lime  estimated  by  the  automatic 
solution,  and  adjustments  in  this  ar;  very'  common  (the  onset  time  method  used  by  Sif^Pro 
requires  improvement  since  the  ana'yst  often  disagrees  with  it).  The  analyst  can  also  add. 
delete,  as.sociate  and  disassociate  pha.ses.  In  the  example  shown  no  Lg  was  detected 
automatically  at  ARCESS,  and  the  analyst  could  add  it  (though  this  poorly-defined  phase 
should  not  be  picked). 

The  ASSESS  solutions  are  written  to  the  detection  (Version  2.8  DBMS),  detloc  (Version  2.8 
DBMS),  and  loc  (Appendix  A)  relations,  with  the  attribute  loc.siatust  written  as  "expert.”  The 
analyst  can  choose  to  validate,  invalidate,  or  change  the  ASSESS  .solution.  Upon  validation  the 
loc.status  attribute  is  changed  to  "valid."  If  the  solution  is  invalidated  or  changed,  loc.status  is 
changed  to  "invalid."  The  new  solution  (or  a  null  solution  if  the  ASSESS  solution  is 
invalidated)  is  written  to  the  loc  relation,  with  links  between  the  ASSESS  and  analyst  loc  tuples 
for  this  "event"  maintained  via  the  locnorid  and  locporid  relations  (Appendix  A).  AH 
detections  that  have  been  altered  arc  written  to  the  detection  relation,  with  the  detloc  relation 
providing  the  links  between  each  loc  tuple  and  its  associated  detection  tuples.  When  a 
detection  is  altered  (renamed,  retimed,  etc.),  the  DBMS  maintains  a  link  between  the  old  and 
new  (analyst)  detection  tuples  by  the  detloc.pdlid  and  detloc. ndlid  attributes.  When  the  analyst 
marks  a  solution  "invalid,"  all  defining  phases  (Pn.  Sn,  etc.)  arc  changed  to  the  corresponding 
undefining  pha.scs  (P,  S)  and  linked  to  the  corresponding  null  tuple  in  loc.  When  the  analyst 
deletes  a  phase,  a  detloc  tuple  is  written  with  detloc  .phase  =  "glitch,"  and  when  the  analyst 
adds  a  phase,  a  new  detection  tuple  is  written  with  detloc.pdlid  =  "null"  in  the  associated 
detloc  tuple. 

In  summary,  the  results  of  analyst  review  arc  written  to  the  DBMS  in  a  way  that  allows  the 
analyst  and  ASSESS  solutions  to  be  compared  in  detail.  This  comparison  is  done  by  the  PerfX' 
process  described  in  the  following  .section. 

t  Intelligent  Array  System  tser  Documentation.  SAIC-8V/I737,  December.  1989. 

t  TTie  status  attribute  in  the  loc  relation 
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ARCESS  Orid;3SI  (e^ert)  S831  N  26M  E  depth; 0.00  km  magiO.O 
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Detection  Opi  IP  Explanation  ||~  Identification 


Figure  4.9  A  typical  "Analyst  Review  Station"  display  of  an  event  solution  (denoted  by 
unique  Grid)  obtained  by  ASSESS  (denoted  "expert").  The  functions  of  the  buttons  on  the 
"Coiiirol  Panel"  at  the  lower  left  arc  described  in  the  IAS  u.ser  documentation.  The  waveform 
display  shows  three  standard  beams  (see  Section  3.8)  from  each  array.  All  detections  in  the 
time  segment  displayed  arc  indicated  by  their  phase  identifiers.  Vertical  lines  below  the  phase 
identifier  indicate  that  the  pha.se  is  associated  with  the  cuircnt  Grid  (i.e..  Grid  351).  The 
expected  arrival  limes  for  Pn.  Pg.  Sn.  Lg  (and  Rg  at  ARCESS)  arc  computed  for  the  locauon 
solution  and  shown  as  vertical  lines  just  above  the  lime  axis.  The  event  solution  has  been  sent 
lo  the  map  program,  and  each  phase  is  plotted  with  a  line  at  the  estimated  azimuth.  The 
location  and  confidence  ellipse  for  the  solution  are  also  plotted. 
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4.7.  KNOWLEDGE  ACQUISITION 

The  concept  for  knowledge  acquisition  in  IAS  was  described  in  Section  2.4.  In  the  current 
implementation  this  concept  is  implemented  in  the  PerfV  (performance  validation)  software 
module.  The  primary  function  of  this  module  is  to  compare  the  analyst  and  ASSESS  solutions 
to  determine  which  elements  of  the  knowledge  base  have  implicitly  been  "validated "  and 
"invalidated"  when  the  analyst  approves  and  corrects  the  ASSESS  solution  This  module  also 
constructs  a  "summary  relation"  which  summarizes  the  most  important  information  about  each 
event  solution  in  an  easily  manipulated  form.  Another  important  aspect  of  the  knowledge 
acquisition  concept  is  a  user-friendly  interface  to  make  it  convenient  for  seismologists  to 
retrieve  and  organize  information  to  guide  the  development  of  new  knowledge  to  be  input  to 
the  system.  In  this  section  each  of  these  aspects  of  the  IAS  knowledge  acquisition  modules  are 
described  in  more  detail. 


4.7.1.  Performance  Validation 

In  the  previous  section  the  DBMS  links  between  ASSESS  and  analyst  solutions  were  described. 
The  important  relations  for  maintaining  the  two  solutions  and  the  links  between  them  are 
detection,  detloc,  loc,  locnorid  and  locporid.  The  PerfV  process  scans  these  relations  to  find 
linked  pairs  of  loc  and  detloc  tuples.t  Rule-based  reasoning  is  used  to  decide  which  element 
of  the  ASSESS  reasoning  process  made  the  decision  that  was  overruled  by  the  analyst  change. 

As  described  in  Section  4.3.4. 1,  the  ASSESS  reasoning  process  is  divided  into  seven  sequential 
KS  classes,  and  seven  sequential  tuples  are  written  to  the  audit  relation  to  identify  the  KS  used 
to  make  the  decision  in  each  class.  The  PerfV  rules  select  the  KS  class  where  the  "error"  was 
made.  The  audit  record  for  this  KS  class  is  marked  "invalid,"  and  the  audit  record  for  earlier 
(in  the  sequence)  KS  classes  is  mariced  "valid.”  Audit  records  for  KS  classes  later  in  the 
sequence  are  then  marked  "ignored"  since  the  error  may  have  co.itaminated  later  steps  in  the 
reasoning  process.  In  some  cases  the  error  cannot  be  unambiguously  attributed  to  one  KS 
class,  and  two  classes  are  marked  "invalid."  If  there  are  KS  classes  between  the  two  in  the 
sequence,  they  are  marked  "ignored."  For  valid  events  PerfV  marks  the  audit  records  "valid” 
for  all  KS  classes. 

The  rules  in  the  current  implementation  of  PerfV  are  listed  in  this  section  according  to  the  KS 
class  or  classes  inferred  to  be  the  cause  of  the  ASSESS  error.  The  first  group  of  rules  examines 
the  changes  made  to  individual  phase  arrivals,  and  the  second  group  looks  at  sets  of  phase 
arrivals.  Each  phase  arrival  has  a  detection  tuple  identified  with  an  arid,  and  each  event 
.solution  has  a  loc  tuple  identified  with  an  orid.  The  rules  for  individual  phase  arrivals  are: 

Signal  Processing  KS  Class 

•  If  two  linked  detloc  tuples  are  associated  with  detection  tuples  that  have  different  arid’s, 
the  analyst  has  retimed  the  phase. 

•  If  the  second  of  two  linked  detloc  tuples  has  detloc  .phase  =  "glitch,"  the  analyst  has 
discarded  this  SigPro  detection  as  a  false  alarm. 

•  If  the  second  of  two  linked  (via  the  locnorid  relation)  loc  tuples  is  associated  with  a 
detloc  tuple  with  detloc.pdlid  =  "null,"  the  corresponding  detection  tuple  has  been  added 
by  the  analyst. 


+  PerfV  can  be  initiated  each  time  the  analyst  completes  an  event,  but  it  is  more  convenient  to  run  it  in 
a  batch  mode  (e.g.,  once  a  day).  As  was  done  several  times  during  the  initial  period  of  IAS  operation  in 
late-1989,  PerfV  can  be  changed  and  rerun  over  the  entire  database  (though  this  requires  approximately 
one  hour  of  computer  time  per  100  events). 
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Initial  Phase  Identification  KS  Class 

•  If  two  linked  detloc  tuples  have  the  same  arid  and  detloc. phase  differs  in  phase  "type," 
the  analyst  has  overridden  the  initial  phase  identification  made  by  ASSESS.  The  phase 
types  arc  P  (P,  Pn,  Pg),  S  (S,  Sn.  Lg,  Rg),  N  (noise)  and  T  (teleseism). 

Detection  Grouping  KS  Class 

•  If  two  linked  detloc  tuples  are  associated  with  loc  tuples  not  linked  via  the  locnorid 
relation,  and  are  not  from  the  same  detection  group,  the  analyst  has  disassociated  this 
phase  from  one  event  and  associated  it  with  another  event. 

Phase  Association  KS  Qass 

•  If  two  linked  detloc  tuples  arc  associated  with  loc  tuples  not  linked  via  the  locnorid 
relation,  and  arc  from  the  same  detection  group,  tlie  analyst  has  disassociated  this  phase 
from  one  event  and  associated  it  with  another  event. 

Final  Phase  Identification  KS  Pass 

•  If  two  linked  detloc  tuples  have  the  same  arid  and  detloc.phase  differ  withir  the  same 
phase  "type,”  the  analyst  has  changed  the  identification  of  this  phase. 

For  the  following  rules  we  compare  patterns  in  the  "initial  detection  group"  (Section  4. 3.2.2) 

generated  by  ASSESS,  the  "ASSESS  detection  set"  associated  with  each  orid  :reatcd  by 

ASSESS,  and  the  "analyst  detection  set"  associated  with  each  orid  written  by  the  analyst.  The 

rules  are: 

Detection  Grouping  and  Phase  Association  KS  Classes 

•  If  there  is  a  detection  in  an  ASSESS  detection  set  which  is  not  in  any  analyst  dcu 

set,  the  analyst  has  removed  this  detection  from  the  ASSESS  solution  and  not  associate”  •’ 
with  another  event. 

•  there  is  a  detection  in  an  analyst  detection  set  which  is  not  in  any  ASSESS  detection 
set,  the  analyst  has  associated  this  previously  unassociated  detection  with  an  event. 

•  If  there  is  one  ASSESS  detection  set  that  is  a  subset  of  an  initial  detection  group,  and 
there  are  two  or  more  analyst  detection  sets  which  include  detections  in  this  initial 
detection  group,  the  analyst  has  invalidated  the  ASSESS  decision  that  there  is  only  one 
event  with  detections  in  this  initial  detectior  group. 

Phase  Association  KS  Gass 

•  If  there  are  two  ASSESS  detection  scLs  which  arc  sub.scLs  of  an  initial  detection  group,  and 
there  are  m  analyst  detection  sets  (m^2)  which  include  detections  in  this  initial  detection 
group,  the  analyst  has  invalidated  the  ASSESS  decision  that  there  are  two  events  with 
detections  in  this  initial  detcctiun  group. 

•  If  there  is  one  ASSESS  detection  set  that  is  a  subset  of  an  initial  detection  group,  and 
there  arc  two  analyst  detection  sets  which  arc  both  sub.sets  of  the  same  initia'  detection 
set,  the  analyst  has  created  two  events  where  ASSESS  found  only  one. 

Event  Grouping  and  Network  Location  KS  Gas.scs 

•  If  >1  stations  contribute  to  the  ASSESS  solution  and  the  analyst  associates  with  this  event 
one  or  more  detections  previously  a.ssociatcd  with  one  or  more  single-station  s'lulioas, 
the  analyst  has  invalidated  the  decision  that  these  dotccti'ins  belong  to  diffcicnt  cvenus. 

•  If  >1  stations  r'-intributc  to  the  ASSESS  solution  end  the  analy.'-i  as.sociatcs  with  ’is  event 
one  or  more  previousl)  unassociated  phases,  the  analyst  has  invalidated  the  decision  that 
these  detections  arc  not  with  any  event. 
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•  If  1  station  contributes  to  the  ASSESS  solution,  and  the  analyst  associates  with  this  event 
one  or  more  detections  from  a  different  station,  the  analyst  has  invalidated  the  decisions 
that  this  is  a  single-array  event  and  the  detections  belong  to  other  events  or  no  event. 

•  If  >  1  stations  contribute  to  an  ASSESS  solutions  which  contains  exactly  two  phases,  and 
the  analyst  invalidates  this  solution,  the  analyst  has  invalidated  the  decisit  n  that  these 
detections  belong  to  the  same  event. 

•  If  >  1  stations  contribute  to  an  analyst  solution  which  contains  exactly  two  phases,  and 
the  detections  were  not  previously  associated  with  an  ASSESS  solution,  the  analyst  has 
invalidated  the  decision  that  these  two  detections  are  una.ssociated.  solution,  the  analyst 
has  invalidated  the  decision  that  these  detections  belong  to  the  same  event. 

Phase  Association.  Event  Grouping  and  Network  Location  KS  Classes 

•  If  two  linked  detloc  tuples  have  the  same  arid,  and  detloc. phase  differs  within  the  same 
phase  "type,"  and  either  an  Sn  was  changed  to  an  Lg,  an  Lg  to  an  Sn,  a  Pn  to  a  Pg,  or  a 
Pg  to  a  Pn,  the  analyst  has  changed  the  identification  of  a  defining  phase. 


4.7.2.  Summary  Relations 

Summary  relations  are  computed  to  characterize  the  gross  features  of  event  solutions  and  any 
differences  between  the  automatic  (ASSESS  and  analyst  results.  They  are  generated  by  a 
portion  of  the  Perf\^  software  module  which  extracts  the  relevant  information  about  events 
from  the  database,  computes  summary  information,  and  inserts  this  information  in  the  summary 
relations.  In  this  section  we  describe  in  detail  the  summary  data  computed  during  the  Fall, 
1989,  operation  of  IAS.  We  note  that  these  relations  arc  easily  changed  and  expanded.  That 
is.  if  new  summary  data  are  needed,  the  PerfV  module  is  modified  appropriately.  It  can  be 
applied  to  the  entire  database  of  past  events  if  desired. 

There  are  two  summary  relations  in  the  current  implementation  of  MS,  as  described  below. 
This  is  followed  by  a  list  of  the  attributes  found  in  each  of  these  relations. 

1.  ev_summary 

This  provides  a  concise  summary  of  important  characteristics  of  each  event  solution. 
There  is  an  entry  in  the  relation  for  each  final  location  produced  by  IAS  (i.e.,  validated 
ASSESS  location  or  analyst  location). 

1.  ex_an 

This  relation  has  an  entry  for  each  linked  pair  of  ASSESS  and  analyst  solutions  that 
summarizes  the  major  differences  between  the  two.  It  also  has  an  entry  for  events  added 
by  the  analyst,  though  most  attributes  are  "null." 

The  entries  in  each  of  thc.se  relations  arc  described  below. 

ev  summary 

orid  Unique  identifier  for  an  origin  (location  solution). 
nearsta  The  nearest  station  to  the  location. 
neardist  The  distance  to  nearsta. 
nearaz  The  azimuth  from  nearsta 

refid  The  identifier  of  the  nearest  "reference  point."  The  IAS  managers  can  specify  these 
locations  of  special  interest  (e.g.,  mines)  as  they  think  appropriate.  The  database 
includes  a  relation  (ref  Joe)  describing  them. 
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refdisi 

refaz 

grn 

nsta 

Ista 

asta 

rsta 

tsta 

ndef 

adef 

primp 

secondp 

depthp 

Iddate 


The  distance  to  the  nearest  "reference  point." 

The  azimutii  to  the  nearest  "reference  point." 

The  Flinn-Engdahl  geographic  region  number. 

The  number  of  stations  with  defining  phases  associated  with  the  event. 

The  number  of  stations  with  associated  phases  that  are  within  250  km  of  the  event 

The  number  of  arrays  with  associated  phases  that  are  at  a  range  between  250  and 
2000  km. 

The  number  of  non-array  stations  with  associated  phases  that  are  at  a  range  between 
250  and  2000  km. 

The  number  of  stations  with  associated  phases  that  are  at  teleseismic  distances  (> 
2000  km). 

The  number  of  defining  phases  (i.e.,  Pn.  Pg,  Sn,  Lg,  Rg)  associated  with  the  event. 
The  number  of  associated,  nondefining  phases  (i.e.,  P  and  S) 

The  number  of  primary  phases  (first  P,  usually  Pn)  associated  with  the  event.  Note 
that  this  is  mainly  for  teleseismic  data,  and  primp  =  nsta  in  IAS,  except  when  the 
associated  phases  at  a  station  do  not  include  Pn  or  Pg. 

The  number  of  secondary  phases  (i.e.,  associated  defining  phases  after  first  P) 
associated  with  the  event. 

The  number  of  depth  phases  (e.g.,  pP,  sP)  associated  with  the  event. 

The  date  these  summary  data  v/ere  inserted  into  the  database. 


forid 

eorid 

ddist 

ddepth 

dtime 

did 

dnsta 

dLsta 

dasta 

drsta 

dtsta 

dndef 


A  unique  identifier  for  a  location  produced  by  the  analyst 
A  unique  identifier  for  a  location  produced  by  the  expert  system. 

The  distance  between  the  forid  location  and  the  corresponding  location  for  eorid. 

The  depth  difference  between  the  forid  location  and  the  corresponding  location  for 
eorid. 

The  origin  time  difference  between  the  forid  location  and  the  corresponding  location 
for  eorid. 

The  event  identification  difference  between  the  forid  location  and  the  corresponding 
location  for  eorid. 

The  difference  in  the  number  of  recording  stations  (eorid  -  forid)  for  the  two 
locations. 

The  difference  in  the  number  of  local  stations  (range  <  250  km)  associated  with  the 
event. 

The  difference  in  the  number  of  regional  stations  (range  between  250  and  2(X)0  km) 
associated  with  the  event. 

The  difference  in  the  number  of  non-array  stations  associated  with  the  event 

The  difference  in  the  number  of  teleseismi.  stations  (range  >  2000  km)  associated 
with  the  event. 

The  difference  in  the  number  of  defining  phases  associated  with  the  event 
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dprimp  The  difference  in  the  primp  for  the  event. 

dsecondp  The  difference  in  the  secondp  for  the  event. 

ddepthp  The  difference  in  the  number  of  depth  phases  (e.g.,  pP,  sP)  for  the  event. 

rprimp  The  number  of  P-type  phases  in  the  analyst  solution  iforid)  for  which  the  phase 

identification  was  changed. 

rsecondp  The  number  of  S-typc  phases  in  the  analyst  solution  iforid)  for  which  the  phase 
identification  was  changed. 

rdepthp  The  number  of  depth  phases  in  the  analyst  solution  iforid)  for  which  the  phase 
identification  was  changed. 

added  The  number  of  phases  added  to  the  event  solution  by  the  analyst. 

retime  Tlie  numbei  of  phases  that  are  in  both  the  analyst  and  expert  system  solutions,  but 

have  been  retimed  by  the  analyst. 

splitev  Indicates  when  the  analyst  solution  includes  detections  which  were  associated  with 
two  or  more  solutions  by  the  expert  system. 

multev  Indicates  when  there  is  another  event  soluiion  within  50  km  which  has  an  origin 
time  that  differs  by  less  than  5  minutes. 

Iddate  The  date  these  nummary  data  were  inserted  into  the  database. 


4.7.3.  User-Interface 

The  IAS  database  provides  a  rich  source  of  information  about  seismic  events  and  comparisons 
between  automatically  generated  and  human-generated  solutions.  Tools  to  retrieve  this 
information  fall  into  three  classes; 


The  most  flexible  and  complete  method  for  retrieving  data  from  the  DBMS  is  directly  via 
the  DBMS  query  language,  SQL.  This  requires  knowledge  of  SQL,  but  this  is  not  very 
difficult  to  acquire.  A  more  significant  barrier  to  effective  use  of  SQL  is  the  requirement 
for  an  intimate  knowledge  of  the  IAS  database  itself.  This  is  not  simply  knowledge  about 
the  relations  and  their  interconnections  (which  is  straightforward  to  learn  from  the 
documentation),  but  also  includes  knowledge  about  the  number  of  tuples  in  specific 
relations  and  its  effect  on  performance  which  comes  mainly  with  experience.  Nevertheless, 
users  requiring  intense  interaction  with  the  DBMS  over  an  extended  period  will  probably 
use  SQL  queries  extensively. 

2.  Standard  Output  and  Menu-Based  Retrieval 

The  standard  output  of  IAS  includes  a  bulletin  (produced  by  the  bull  process,  hardcopy 
display  of  the  solutions  (produced  by  EvPlot),  and  dynamic  display  of  solutions, 
explanation,  etc.,  via  ARS  (Section  4.6).  The  bulletins  are  published  and  distributed  by  the 
Center  for  Seismic  Studies, t  and  they  include  numerous  EvPlot  displays  (see  Section  VI 
for  examples).  Also  falling  within  this  category  are  the  DBS  process  and  the  "Executive 
Review  Station"  iERS),  and  these  are  described  in  later  subsections. 


The  SQL  queries  have  unlimited  flexibility,  but  require  great  knowledge  of  the  system  to 


t  As  of  February,  1990.  bulletins  have  been  published  for  1  October  to  18  November,  1989.  Request 
copies  of  these  and  subsequent  bulletins  (starting  in  January.  1990)  from  Center  for  Seismic  Studies,  Suite 
1450,  1300  N.  17th  Street.  Arlingon  VA  22209-3871. 
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use  effectively.  The  standard  output  and  menu-based  retrieval  systems  arc  very  easy  to 
use,  but  have  limited  flexibility.  What  occasional  users  most  need  is  an  interface  that  is 
both  flexible  and  easy  to  use.  An  interface  that  provides  an  important  advance  toward  this 
objective  is  the  iastalk  process  described  in  a  later  subsection. 

4.7 .3.1.  The  Database  BrowserlSector  (DBS)  Process 

The  DBS  user-interface  is  the  form  shown  in  Figure  4.10.  The  user  fills  in  this  form  (or  uses 
the  default  values)  to  bound  a  query  to  the  loc  relation.  The  results  of  this  query  arc  listed  by 
loc.orid  in  a  "results"  window.  Grid’s  of  interest  can  then  bf  selected  and  sent  via  IPC 
messages  to  other  IAS  processes;!"  currently,  these  are  map,  ARS,  DA,  Review,  Run,  MERSY, 
EvPlot.  Further  details  on  this  process  arc  provided  in  the  IAS  User  Documentation. 

4.7.3.2.  The  Executive  Review  Station  (ERS) 

This  process  provides  a  high-level  interface  to  the  IAS  database  (sec  the  IAS  User 
Documentation  for  a  detailed  description).  'Fhc  user-interface  is  a  slightly  modified  DBS  form 
and  maps  provided  by  the  map  process.  Selected  events  are  plotted  on  the  selected  map.  The 
IAS  map  process  allows  selection  of  maps  at  many  scales  and  several  projections.  The  largest 
map  is  a  Mercator  projection  of  the  earth’s  surface  between  ±  75°  latitude.  Also,  there  arc 
azimuthal-equidistant  projection  maps  of  tlic  aiea  within  2000  km  of  the  NORESS  array  at  two 
scales.  Measured  horizontally  on  a  16-inch  screen,  the  scale  of  these  maps  is  approximately 
170  km/cm  and  43  km/cm.  These  large-area  maps  were  made  by  processing  elevation  data 
from  World  Data  Center  A.  For  selected  areas  in  the  northwestern  Soviet  Union,  there  are  also 
maps  at  a  scale  of  11  km/cm  made  by  processing  DMA  digital  terrain  elevation  data  and 
selected  feature  data.  SPOT  images  can  also  be  displayed  for  a  few  selected  rreas  at  a  scale  ol 
-2  km/cm  on  a  16-inch  monitor. 

Events  can  be  selected  by  a  point-and-click  interface  to  the  map.  Information  about  the 
selected  event  (location,  magititudc,  event  identification,  etc.)  can  be  obtained  in  this  way. 
Thus,  the  ERS  provides  a  good  interface  for  browsing  location  information  in  the  database. 
Waveforms  cannot  be  examined  with  this  interface. 

4.7.3.3.  The  Natural-Language  Interface 

The  ability  to  retrieve  data  from  a  relational  database  by  typing  English  queries  has  obvious 
advantages.  Many  products  to  provide  this  capability  are  under  development  in  both  large 
companies  and  small  startup  companies  funded  by  venture  capital.  The  technology  is  still  in 
its  infancy,  and  there  are  major  problems  that  remain  to  be  overcome  before  it  can  realize  its 
promise. 

The  iastalk  process  is  implemented  with  the  "NL"  product  developed  by  Natural  Language, 
Inc.  This  product  was  selected  after  evaluation  of  several  alternatives.  Basically,  it  works  by 
parsing  English  questions  to  generate  SQL  queries  to  the  DBMS.  Natural-language  parsing  is 
a  major  topic  of  current  research  in  computer  sciences,  and  the  designers  of  NL  (Jerrold 
Ginsparg  and  John  Manferdelli)  are  among  the  leading  participants. 

Natural  Language  (NL)  customization  requires  a  thorough  understanding  of  the  problem 
domain.  It  involves  a  mapping  of  the  English  constructs  used  by  seismologists  to  the 
corresponding  relational  database  entities  (relations  and  attributes).  For  IAS  this  mapping  was 
done  for  the  loc,  detloc,  detection,  locnorid,  locporid,  ev_summary,  ev_an  and  audit  relations. 
This  means  that  attributes  stored  in  these  relations  can  be  obtained  with  English  queries  that 


t  See  Section  III  for  a  description  of  these  processes  and  IPC  messages. 
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Figure  4.10.  The  DBS  user  interface  is  shown  with  default  values  for  the  upper  and  lower 
bounds  on  each  attribute  in  the  form.  The  user  can  change  any  of  these  bounds  by  typing  in 
die  appropriate  space  at  the  right.  The  number  of  table  entries  satisfying  the  specified  bounds 
is  returned  in  the  window  at  the  bottom  when  "Query"  is  selected.  In  this  case  Database idemo 
has  only  27  entries. 
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the  NL  parser  is  able  to  understand  and  construct  the  appropriate  SQL.  The  parser  must  apply 
much  knowledge  and  reasoning  ability  to  resolve  (or  recognize  and  request  clarification) 
ambiguities  in  typical  queries  made  by  seismologists.  Since  the  knowledge-base  included  with 
the  NL  product  is  oriented  toward  business  applications,  the  seismology-specific  meaning  of 
terms  like  distance,  time,  location,  etc.  had  to  be  added. 

TTie  NL  product  was  customized  by  SAIC  and  NLI  (under  subcontract)  using  a  list  of  about 
150  typical  queries.  These  queries  and  straightforward  variations  of  them  arc  understood  by 
the  current  version  of  iastalk.  However,  there  arc  deficiencies  of  this  version  that  limit  its 
utility  for  general  use  as  an  inteiface  to  the  IAS  database.  One  deficiency  is  that  it  has  been 
customized  for  only  a  portion  of  the  database  (albeit  the  most  interesting  relations  for  most 
purposes).  Al.so,  there  arc  knowledgc-ba.se  gaps,  .so  imtalk  may  fail  to  understand  different 
formulations  of  queries  it  docs  understand.  More  serious  deficiencies  arise  as  a  side-effect  of 
the  flexibility  that  is  one  of  the  most  attractive  aspects  of  the  natural-language  interface.  These 
are: 

•  Experience  shows  that  seismologists  arc  remarkably  imprecise  in  their  queries.  Thus, 
they  must  Icam  by  experience  to  .state  clearly  what  they  want.  This  is  a  frustrating 
process  for  the  novice  user,  since  the  training  takes  place  by  through  trial-and-error. 

•  The  flexibility  allows  the  user  to  make  impractical  queries  requiring  a  linear-search  of 
large  tables. 

Thus,  iastalk  provides  an  interesting,  but  not  yet  practical  interface  to  the  IAS  database  for 
novice  u.scrs.  Work  is  continuing  under  another  project  (NMRD)  to  provide  a  more  structurco 
interface  ("NL  Query”)  to  NL  to  overcome  the  limitations  outlined  above.  This  interface  will 
provide  guidance  to  make  practical  queries  that  arc  guaranteed  to  parse.  This  introduces  some 
limitations  on  the  flexibility,  but  the  NL  Query  interface  will  be  more  flexible  than  ARS,  DBS, 
etc.,  and  far  easier  to  use  than  direct  SQL  queries. 
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The  computer  configuration  used  for  operation  of  IAS  October-November,  1989  is  shown  in 
Figure  5.1.  The  LAN’s  at  the  Center  and  at  NDAC  are  shown  in  separate  drawings.  The  two 
are  connected  with  a  Proteon  gateway  implemented  on  Proteon  4200-10  computers  at  the  two 
sites  The  Proteon  units  route  inter-LAN  packets  over  the  satellite  link,  creating  a  wide-area 
network  (WAN). 

As  shown  in  Figure  5.1,  IAS  is  implemented  on  seven  Sun  workstations  plus  an  IV AS  image 
processing  and  display  system  (Section  4.6.x).  Each  Sun  woiicstation  is  identified  by  model 
number  and  monitor  (C  is  19"  color,  M  is  19"  monochrome,  HM  is  19"  high-resolution 
monochrome,  CE  is  16"  color,  S  indicates  no  monitor).  The  computers  are  named  for  figures 
in  Norwegian  mythology,!  and  these  names  are  indicated.  Also  shown  for  each  computer  is 
the  number  of  megabytes  (MB)  of  physical  memory  and  any  attached  disks  (indicated  by 
unformatted  capacity).  The  IVAS  is  an  image  display  device,  and  it  includes  an  interface 
board  installed  in  Mimer  (indicated  by  a  line  in  Figure  5.1b)  to  use  the  Sun  CPU  for  image 
processing. 

There  are  many  acceptable  ways  to  install  the  software  on  this  hardware  configuration.  In  the 
figure  we  show  the  installation  used  for  most  of  the  October-November,  1989  operation  of  IAS. 
Only  the  major  processes  among  the  43  listed  in  Section  111  arc  shown.  The  others  (for 
example,  the  various  "agents")  are  small  enough  to  be  installed  almost  anywhere. 

The  freedom  to  move  processes  from  one  machine  to  another  is  limited  by  requirements  for 
effective  performance.  Some  of  the  performance  requirements  are  objective  (maintain  pace 
with  the  real-time  data  stream)  while  others  are  more  subjective  ("adequate"  response  to  user 
requests).  A  Sun  4/260  can  handle  the  SigPro  processing  for  a  single  array,  even  if  an  Ingres 
or  Oracle  DBMS  is  sharing  the  machine  (Figure  5.1a).  However,  a  less-capable  machine  (e.g.. 
Sun  3/260)  would  not  be  adequate  for  this  processing.  At  the  Center  (Figure  5.1b)  ASSESS 
and  the  DBMS  each  require  a  Sun  4/260  with  large  physical  memory  (32  MB)  for  satisfactory 
performance,  so  they  cannot  coexist  on  the  same  machine.  Lisp  processes  (see  below)  usually 
require  16  MB  memory  for  satisfactory  performance,  though  the  Manager  performance  is 
satisfactory  with  less. 

Since  the  X  Window  System  is  used  for  all  graphics,  the  screen  displaying  the  output  of  a 
process  (the  X  Window  "server")  can  be  anywhere  on  a  LAN  shared  with  the  computer 
executing  that  process  (the  X  Window  "client").  The  main  user-interface  processes  are  ARS  and 
Map,  and  these  processes  are  most  effective  when  the  X  Window  server  is  on  a  Sun  4  (4/110, 
SparcStation,  or  larger)  with  at  least  16  MB  memory.  The  map  program  requires  a  color 
monitor.  The  other  graphics  produced  by  the  system  can  be  displayed  on  either  color  or 
monochrome. 

The  IAS  system  requires  the  following  licenses  for  commercial  software  products: 

Relational  DBMS 

Ingres  An  8-user  Ingres  license  is  required  for  operation  at  the  Center.  During  the  first 
part  of  the  October-November  operation,  Ingres  was  used  at  NDAC.  A  change  was 
made  to  Oracle,  which  has  been  used  for  the  SigPro  et  al.  DBMS  since. 

Oracle  A  16-user  (the  smallest  increment)  Oracle  license  is  required  for  the  signal 
processing  part  of  the  IAS  at  NDAC. 


t  For  example,  see  E.  B.  Tichenell,  The  Masks  of  Odin,  Theosophical  University  Press,  1985. 


HARDWARE  ARCHITECTURE 


95 


Figure  5.1a.  The  NDAC  LAN  with  the  installation  of  major  software  processes  during 
October  -  November,  1989. 
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Figure  5.lh.  The  Center  LAN  with  the  installation  of  major  software  processes  during 
October  -  November,  1989. 


LISP 

Franz 


Allegro  CommonLisp  is  required  for  ASSESS,  Perf\',  Manager  and  ScriptMatch. 


Natural-Language  Interface 

NL/  The  Natural  Language  licensed  by  Natural  Language,  Inc.  is  required  for  iastalk. 

NCAR  Graphics 

Minesoft  A  commercial  version  of  NCAR  graphics  software  licensed  by  Mincsoft,  Inc.  is 
required  for  the  hardcopy  plots  produced  by  EvPlot. 

X  Window  System 

MIT  This  portable  standard  for  network  graphics  is  available  at  no  cost  from  MIT’s 
Project  Athena. 

PostScript  Translator 

Adobe  This  product  is  required  to  convert  text  (from  troff)  and  graphics  (e.g.,  from 
Mincsoft  graphics)  to  a  form  compatible  with  PostScript  laser  printers. 
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6.1.  Format 

The  examples  arc  summarized  in  Table  6.1.  Each  is  idcnlificd  by  a  sequence  number  which 
idcniifies  the  figures  detailing  this  example.  Also  listed  in  the  table  arc  the  approximate  origin 
time  {mmddhhmm)  computed  by  ASSESS  and  the  difference  between  the  ASSESS  and  analyst 
solutions.  This  difference  is  characterized  by  two  attributes  from  the  ex_an  relation  (Section 
A .1.2).  The  dndcf  is  the  difference  in  the  number  of  defining  phases,  and  the  cldi.si  is  the 
distance  separating  the  ASSESS  and  analyst  locations.  The  "Dist.  to  Hcl.”  is  the  separation 
between  the  IAS  analyst  location  an  independent  network  location.  Many  of  these  events  were 
not  detected  by  this  large  network. 

The  figures  arc  produced  by  the  EvPlot  process.  The  ASSESS  and  analyst  solutions  appear  on 
facing  pages  in  the  same  format.  Each  includes  a  listing  of  the  results,  waveforms  from  both 
arrays,  and  a  map.  At  the  top  is  the  final  solution,  with  SMaj,  SMin,  Strike  characterizing  the 
909(  confidence  limits  on  the  location  solution.  The  single-array  locations  arc  also  listed,  and 
compari.son  with  the  multiple  array  locations  .shows  the  advantage  of  the  second  array.  All 
detections  in  the  waveform  time  window  arc  listed  with  their  phase  identifier  and  various 
quantities  determined  by  SigPro  (Section  4.1).  These  arc  the  origin  time,  the  standard 
deviation  on  the  origin  time  (Tsd),  the  beam  identifier  (Bmn,  .see  Table  4.1).  four  quantities 
from  the  f-k  solution  (Vcl,  Dvcl,  Azim,  Asd),  the  short-term  average  amplitude  (Stavg)  on  the 
detecting  beam,  the  frequency  determined  during  the  analysis  of  the  detecting  beam,  and  the  f- 
k  quality  (Fkq).  The  P  and  Spl  are  the  Ppolar  and  Spolar  described  in  Section  4.3.2. 3.  The 
Grid  is  a  unique  event  identifier.  Phases  with  the  same  Grid  arc  a.s.sociaied  witli  the  same 
event.  In  the  detection  listing  for  the  analyst  solution  there  arc  u.sually  entries  with  "??"  in  the 
column  for  the  pha,sc  identifier.  This  shows  the  original  SigPro  attributes  for  a  detection  that 
has  been  retimed  by  the  analyst.  The  amount  of  the  change  can  be  seen  by  comparing  the  "??" 
entry  to  the  entry  that  is  identical  except  for  the  origin  time  and  Grid.  Al.so,  when  the  analy.st 
adds  a  pha.se,  the  SigPro  quantities  arc  not  computed,  so  analyst  added  detections  have  "-1"  in 
the  attribute  columns.  Events  located  by  the  HeLsinki  bulletin  show  that  location  on  the  analyst 
solution.  Precision  of  3  digiLs  indicates  that  the  Helsinki  analyst  located  the  event  in  a  known 
mine  based  on  the  waveform  patterns. 

The  waveform  displays  show  7  minutes  of  three  .standard  beams  from  each  array.  The  beam 
marked  "CB"  is  a  coherent  beam  of  all  vertical  channels  filtered  at  4-K  Hz.  and  steered  toward 
the  estimated  location  at  an  apparent  velocity  of  8.1  km/sec.  The  "HB"  is  an  infinite  velocity 
incoherent  beam  of  the  horizontal  channels  filtered  at  1-4  Hz.  The  "IB"  is  an  infinite  velocity 
incoherent  beam  of  all  vertical  channels  filtered  at  1-4  Hz.  All  detections  in  the  time  window 
arc  marked  with  their  pha.se  identifier.  A  vertical  line  through  the  seismograms  marks 
detections  associated  with  the  event  plotted  on  the  map.  The  theoretical  arrival  time  of  the 
four  main  regional  pha.ses  expected  from  that  location  arc  marked  at  the  bottom  of  each 
display,  and  the  time  window  for  the  plot  begins  30  seconds  before  the  theoretical  Pii  arrival 
time.  The  map  .shows  the  location,  confidence  ellipse,  and  azimuth  of  the  defining  phases. 
Phases  added  by  the  analy.st  have  no  azimuth,  .so  these  new  pha.sc.s  do  not  appear  on  the  map. 

In  the  following  pages  each  of  the  examples  in  Table  6.1  is  detailed  with  figures  showing  the 
ASSESS  and  analy.st  solutions  along  with  comments  on  the  most  important  features  of  each 
example.  The  comments  arc  given  in  subsections  organized  according  to  the  subheadings  in 
the  Table. 
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TABLE  6.1 

Comparison  Between  ASSESS  and  Analyst  Solutions 


# 

Origin 

Time 

dndef 

ddist 

(km) 

Dist.  to 
Hel.Ocm)^ 

Comments 

Correct  Solutions  by  ASSESS 

1 

11161221 

0 

0 

- 

Validated 

2 

10290212 

0 

32 

- 

Minor  retiming 

3 

11011559 

0 

3.5 

10 

Minor  retiming 

Refinement  by  Adding  Detections 

4 

10311955 

0 

A. 

37 

21 

Questionable  pha.scs  added 

i  ^ 

11011814 

2 

18 

- 

Emergent  Lg  undetected 

6 

11021214 

3 

19 

25 

Questionable  pha.scs  added 

7 

11101012 

2 

89 

- 

Interfering  phase 

8 

11161224 

22 

45 

Questionable  Sn  added 

ASSESS  Confu.sed  by  Missing  Detections 

9 

11011225 

afcr 

194 

31 

Missing  Sn  at  NORESS 

10 

11011302 

2 

250 

23 

Missing  Sn  at  ARCESS 

Single 

Array  Solutions 

11 

11011239 

0 

58 

- 

Error  due  to  prccurser 

12 

11010816 

2 

22 

- 

1  event  or  2? 

13 

11011144 

1 

161 

- 

Incorrect  Pg 

14 

11011237 

1 

174 

- 

2  events 

15 

11012332 

1 

61 

- 

3  events 

Rejected  Events 

16 

11010740 

2 

- 

- 

Invalidated  Lg  +  Lg 

17 

10311244 

2 

- 

- 

Invalidated  Sn  +  Lg 

Difficult  Cases 

18 

11011228 

0 

649 

55 

Ambiguous  solution 

19 

11020942 

0 

308 

- 

False  corroboration 

Mixed  Events 

20 

11020819 

3 

22 

- 

Multiple  explosion  in  mine 

21 

11020820 

0 

403 

- 

Multiple  explosion  in  mine 

22 

11040700 

- 

- 

- 

Rejected  solution 

23 

11040701 

1 

278 

25 

Multiple  explosion  in  Baltic  Sea 

24 

11040703 

1 

261 

25 

Multiple  explosion  in  Baltic  Sea 

^Distance  between  the  IAS  analyst  location  and  the  location  in  the  University  of  Helsinki  bulletin  (recent  editions 
list  98  contributing  sutions  in  the  Nordic  countries.)  Tnc  indicates  that  the  event  does  not  apjicar  in  that  hul 
letin. 
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62.  Correct  Solutions  by  ASSESS 

A  few  examples  illustrate  that  IAS  often  obtains  excellent  solutions: 

1.  A  valid  single-array  solution 

The  system  has  no  difficulty  with  simple  local  events  such  as  the  ARCESS  solution 
shown  which  was  "validated"  by  the  analyst  (no  changes).  By  coincidence,  a  local  event 
occured  north  of  NORESS  in  this  time  window,  and  the  analyst  changed  the  ASSESS 
solution  only  slightly  to  add  Pg. 

2.  Minor  retiming  of  a  multiple-arrav  .solution 

The  onset  time  estimator  in  SigPro  does  not  do  very  well  in  picking  the  onset  time  an 
analyst  prefers.  Thus,  the  analyst  often  makes  adjustments  to  the  onset  time,  and  these 
almost  always  tighten  the  confidence  bounds  on  the  solution.  In  this  example  the  anal yst 
has  retimed  the  two  Pn  phases,  moving  ’he  location  32  km,  and  reducing  the  confidence 
bounds  significantly.  A  Pn  from  another  event  and  two  apparent  tcleseisms  also  appear 
in  the  ARCESS  window. 

3.  Minor  retiming  of  a  multiple-arrav  solution 

Again,  the  analyst  has  retimed  both  Pn  phases,  but  this  time  by  so  little  that  the  location 
moved  by  only  3.5  km.  Tlic  Helsinki  bulletin  put  this  event  in  a  mine,  and  both 
solutions  are  within  10  km  of  its  location  which  is  only  given  to  the  nearest  0.1°  (about 
5.5  km  in  latitude). 

6.3.  Refinement  by  Adding  Detections 

The  analyst  often  sees  detections  that  SigPro  missed,  but  is  y  nctimes  guided  by  the 
theoretical  arrival  times  to  pick  detections  that  would  not  otherwise  lx  picked.  It  is  debatable 
whether  operational  pwlicies  should  allow  these  otherwise  undetectable  phases  to  be  added  by 
the  analyst,  but  it  was  allowed  under  pwlicies  in  force  at  the  time  these  data  were  reviewed. 

4.  Adding  subtle  detections 

In  this  example  the  analyst  has  added  very  subtle  detections  at  NORESS.  Without  the 
guidance  of  the  theoretical  arrival  times  it  is  unlikely  that  these  would  be  picked.  This 
example  also  illustrates  another  subtle  change  at  ARCESS.  The  analyst  has  shifted  the 
Lg  from  the  last  to  the  second  of  the  four  detections  in  the  Lg  wavetrain.  These  changes 
and  the  retiming  of  both  Pn  move  the  location  by  37  km,  though  well  within  the 
confidence  limits  on  the  ASSESS  solution.  As  can  be  seen  in  the  detection  listings, 
ASSESS  formed  and  the  analyst  rejected  a  two-phase,  two-array  event  wnh  the  late  Lg  at 
NORESS  and  Sn  at  ARCESS.  This  is  common,  and  will  be  discussed  in  Section  6.6. 

5.  Adding  Detections 

The  emergent  Lg  at  NORESS  is  easily  seen  (though  difficult  to  time),  and  was  added  by 
the  analyst.  These  are  very  difficult  phases  for  the  automatic  detector.  The  Sn  was 
detected  at  ARCESS,  but  ASSESS  failed  to  identify  it.  The  analyst  added  this  Sn.  These 
changes  together  with  retiming  several  phases  move  the  location  18  km. 

6.  Adding  Detections 

The  analyst  added  a  rather  subtle  Sn  at  NORESS  and  very  subtle  Sn  and  Lg  at 
ARCESS.  The  result  is  a  shift  of  the  location  by  19  km.  The  complex  pattern  of 
detections  at  the  end  of  the  segments  can  be  partially  understood  by  studying  the  listings. 
There  is  a  local  event  at  NORESS,  and  Pn  at  both  arrays  from  a  larger  event. 

7.  Adding  Detections 

Here  the  analyst  validated  ASSESS  for  NORESS  except  for  some  minor  retiming,  but 
added  subtle  Sn  and  Lg  at  ARCESS.  This  Sn  is  obscured  by  a  regional  P  (velocity  6. 1 
km/sec)  arriving  Irom  the  northwest.  These  changes  move  the  location  by  89  km. 
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8.  Adding  Detections 

In  this  example  the  analyst  added  a  questionable  Sn  at  ARCESS  and  changed  the 
undehning  P  at  NORESS  to  Pg.  The  location  moved  22  km  as  a  result. 

6.4.  ASSESS  Confused  by  Missing  Detections 

These  two  examples  of  events  occuring  37  minutes  apart  show  the  difficulty  of  developing 
rules  that  work  in  general  even  for  fairly  small  regions.  In  these  examples  the  problem  is  with 
the  rules  for  deciding  whether  an  S  detection  is  Sn  or  Lg  Experience  with  examples  like  these 
has  led  to  new  rules  which  will  be  implemented  in  the  next  version. 

9.  Missing  Sn  at  NORESS 

The  subtle  Sn  at  NORESS  was  not  detected,  but  one  of  the  detections  of  Lg  was  on  a 
horizontal  beam  (Bmn  =  221),  so  ASSESS  identified  it  as  Sn.  The  Sn  was  also  missed  at 
ARCESS,  but  the  Lg  was  identified  correctly.  Fixing  the  error  and  adding  the  missing 
phases  moves  the  location  by  194  km,  which  is  about  30  km  outside  the  confidence 
ellipse  on  the  first  solution. 

10.  Missing  Sn  at  ARCESS 

The  NORESS  detections  are  similar  to  those  in  the  previous  example,  but  this  time  the 
Sn  was  detected  instead  of  Lg,  and  the  rules  identify  it  correctly.  However,  the  same 
rules  fail  at  ARCESS  where  Lg  was  detected  instead  of  Sn  (the  main  problem  is  that  too 
much  weight  is  given  to  the  fact  that  Sn  is  detected  on  horizontal  beams  more  often  than 
Lg).  The  analyst  also  added  Lg  at  NORESS,  though  the  timing  would  be  questionable 
without  the  guidance  of  the  expected  arrival  time.  Making  these  changes,  the  analyst 
moves  the  location  by  250  km. 

6J5.  Single  Array  Solutions 

Small  events  are  detected  on  only  one  array.  Example  #1  showed  an  easy  local  event.  In  this 
section  we  give  other  examples  illustrating  problems  that  occur.  The  rules  in  the  current 
generation  of  ASSESS  are  based  primarily  on  NORESS  experience.  ARCESS  is  somewhat 
different,  and  niles  specifically  for  this  array  are  being  developed  by  analyzing  results  of 
examples  like  those  shown. 

1 1.  NORESS  Error  Due  to  Precurser 

In  this  example  a  precurser  P  detection  is  incorrectly  identified  as  the  Pn  for  this  local 
event.  Both  the  low  frequency  and  relative  amplitude  (with  respect  to  Lg)  make  it 
obvious  that  this  is  incorrect,  and  the  later  high  frequency,  large  amplitude  P  is  actually 
the  Pn.  Correcting  the  error  moves  the  location  58  km.  Rules  to  account  for  relative 
amplitude  and  frequency  content  must  be  added  to  deal  with  situations  like  this. 

12.  Ambiguous  ARCESS  Solution 

ASSESS  identified  Pn  and  Sn  from  the  five  detected  phase.  The  analyst  refined  the 
solution  by  adding  Pg  and  Lg  (the  times  fit  well)  and  doing  some  minor  retiming.  These 
changes  move  the  location  by  22  km,  well  within  the  confidence  ellipse  on  cither 
solution.  Signals  from  explosions  in  mines  on  the  Kola  Peninsula  are  very  common  at 
ARCESS,  bi"  this  location  does  not  seem  to  be  in  a  known  mine.  Also,  the  signals  look 
different  from  typical  mine  blasts  in  this  area.  This  suggesLs  that  these  are  actually 
signals  from  two  explosions  in  the  same  mine  about  7  seconds  apart  (the  separation  of 
the  P  detections).  Either  intciprctation  might  be  correct,  and  resolving  the  ambiguity 
requires  examination  of  typical  waveforms  from  many  other  events  in  the  area. 
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13.  Incorrect  Pg  at  ARCESS 

The  P  detected  at  ARCESS  is  incorrectly  identified  as  Pg  based  on  its  polarization. 
Also,  ASSESS  failed  to  identify  the  Lg.  Fixing  these  errors  moves  the  location  by  161 
km,  but  again  well  within  the  large  confidence  ellipse  on  the  ASSESS  single-array 
location. 

14.  Multiple  Event  at  ARCESS 

Events  in  close  succession  at  the  same  location  are  very  difficult  to  unravel  with  data 
from  a  single  array.  Looking  at  the  ASSESS  ARCESS  waveforms,  the  detections  arc  Pn 
or  Pg  (the  two  are  essentially  the  same  at  this  range  near  the  crossover),  a  stray  S,  Pn 
from  the  second  event  mixed  with  Lg  from  the  first  event,  then  Lg  from  the  second 
event.  ASSESS  correctly  concluded  that  there  were  >  2  events  in  the  sequent  ut  failed 
to  put  them  together  properly  (it  was  probably  confused  by  the  stray  S  detection).  The 
analyst  identified  the  first  P  as  Pn,  added  a  Pg  2  seconds  later,  and  correctly  identified 
the  Lg.  It  appears  that  the  analyst  did  not  complete  the  solution  for  the  second  event  at 
the  same  location. 

15.  Multiple  Event  at  ARCESS 

This  is  another  complicated  event  at  ARCESS  with  no  detections  at  NORESS  to  help. 
Clearly,  ASSESS  incorrectly  concluded  that  there  was  only  one  event.  Careful  study  of 
the  data  suggests  that  there  are  probably  three  events  separated  by  about  10  seconds. 
The  analyst  seems  to  have  correctly  picked  the  first  of  the  three,  but  did  not  complete  the 
solution.  There  are  several  possible  interpretations  that  might  be  correct.  In  this  case  it 
appears  that  the  two  events  are  separated  by  only  about  9  seconds,  so  ASSESS  failed  to 
see  that  there  are  actually  two  events.  The  analyst  located  the  first  event  in  the  sequence 
correctly,  but  appears  to  have  not  completed  the  solution  for  the  second  (which  is 
perhaps  twice  as  large). 

6.6.  Invalidated  Events 

Waveforms  are  retrieved  routinely  for  analyst  review  only  when  ASSESS  forms  an  event. 
Therefore,  the  rules  are  designed  to  seek  an  event  to  explain  as  much  of  the  data  as  possible. 
This  bias  toward  false  events  reduces  the  possibility  of  missing  true  events.  It  turns  out  that 
about  25%  of  the  event  solutions  constructed  by  ASSESS  consist  of  one  phase  at  each  array. 
Unless  the  analyst  is  able  to  find  additional  detections,  these  two-phase,  two-array  solutions  are 
routinely  invalidated.  The  EvPlot  output  for  two  examples  are  shown  on  facing  pages. 

16.  Two  Lg  Location 

Two  reasonable  Lg  detections  are  combined  for  the  solution  in  this  example.  It  could  be 
a  real  event,  but  two  Lg  is  not  enough  to  validate  it. 

17.  Location  from  Sn  and  Lg 

This  solution  is  less  plausible  than  the  previous  example. 

6.7.  Difficult  Cases 

These  examples  show  difficult  events  with  weak  signals. 

18.  Misidentified  Lg  at  NORESS 

The  ASSESS  solution  is  suspect  due  to  the  lack  of  energy  around  the  expected  Lg  arrival 
time  at  NORESS.  The  analyst  changed  the  NORESS  Sn  to  Lg,  but  the  result  is  a 
location  that  seems  too  far  from  the  NORESS  azimuths.  However,  the  apparent  energy 
near  the  ARCESS  Lg  arrival  time  gives  this  solution  some  credibility.  The  Helsinki 
bulletin  locates  this  event  within  55  km  of  the  analyst  location. 
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19.  Misidentified  ARCESS  Pg 

In  this  example  the  ARCESS  Pn  is  misidentified  as  Pg  during  backtracking  to  find 
corroborating  phases  at  NORESS  (i.e.,  the  Pg  +  Sn  at  ARCESS  is  corroborated  by  an  Sn 
at  NORESS).  When  the  analyst  corrects  this  error  (also  adding  an  Lg  that  appears 
undetectable),  it  becomes  clear  that  the  NORESS  detections  cannot  be  from  this  event. 

6,8.  Signals  From  Mixed  Events 

As  noted  previously  (examples  #14  and  #15),  events  in  close  succession  arc  difficult  to 
unravel.  However,  several  large  explosions  in  close  succession  at  the  same  mine  are  often 
seen  in  this  area.  Some  examples  are  shown  here. 

20.  1st  of  a  Multiple  Event  Sequence  in  Kola  Peninsula  Mine 

In  this  complex  sequence  there  are  two  sets  of  ASSESS  and  analyst  plots.  ASSESS 
correctly  concluded  that  there  were  two  Kola  Peninsula  events.  The  firs:  is  large  enough 
to  be  detected  at  NORESS.  The  analyst  corrected  this  solution  by  adding  the  Sn  which 
was  not  detected  at  NORESS,  adding  the  identification  of  Pg  and  Sn  at  ARCESS,  and 
doing  some  minor  retiming.  The  location  is  thereby  shifted  by 

21.  2nd  of  a  Multiple  Event  Sequence  in  Kola  Peninsula  Mine 

This  event  appears  to  be  in  the  same  mine  about  one  minute  later.  ASSESS  entirely 
tailed  because  SigPro  failed  to  detect  the  P  waves  which  can  be  seen  before  the  Sn  in 
the  ASSESS  solution.  The  analyst  added  both  Pn  and  Pg  and  moved  Lg  to  an  earlier 
time. 

22.  Fictitious  Event 

This  is  a  fictitious  event  arising  from  errors  in  the  multiple  event  sequence  (examples 
#23  and  #24)  and  the  coincidental  detection  of  an  S  phase  which  was  mistaken  for  an  Lg 
from  this  fictitious  event. 

23.  1st  of  a  Multiple  Event  Sequence  in  the  Baltic  Sea 

These  two  events  occured  about  36  seconds  apart  at  about  the  same  location.  Only  the 
Pn  were  detected  at  ARCESS,  but  both  Pn  and  Lg  were  detected  at  NORESS.  ASSESS 
correctly  recognized  that  there  were  two  events  with  mixed  signals  at  NORESS,  but  put 
them  together  incorrectly.  The  mistake  was  not  corrected  during  network  processing. 
The  analyst  rearranged  the  NORESS  detections  and  correctly  associated  the  ARCESS  Pn. 
The  location  was  moved  to  the  east  278  km. 

24.  2nd  of  a  Multiple  Event  Sequence  in  the  Baltic  Sea 

The  second  event  follows  easily  from  the  solution  from  the  first.  The  location  moves  to 
the  west  about  261  km. 
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Figures  illustrating  the  examples  in  Table  6.1  appear  in  the  following  pages. 
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APPENDIX  A 

DATABASE  STRUCTURE  FOR  IAS 


The  database  schema  used  in  IAS  is  an  extension  of  the  "Center  for  Seismic  Studies  Database 
Structure  Version  2.8"  (Brennan,  1987).  These  extensions  are  described  in  this  Appendix. 
Figure  A.l  is  an  entity-relationship  diagram.  Figures  A.2  and  A. 3  are  data  flow  diagrams  that 
show  how  the  database  is  updated  by  individual  IAS  processes.  The  "pipeline"  processes  are 
those  active  during  automated  processing  of  the  data.  The  "knowledge  acquisition  system" 
(KAS)  processes  are  those  active  during  and  after  analyst  review  of  the  automatic  solutions. 
Following  the  figures  are  tables  that  are  new  or  changed  from  Version  2.8.  They  are  presented 
in  the  standard  format  for  describing  the  Center  for  Seismic  Studies  Databa.se  Structure  (e.g., 
Brennan,  1987). 
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azimuth  confidence 

dctex 

f4 

f6.2 

88-93 

Expected  detection  snr 

detsd 

f4 

f6.2 

95-100 

detection  snr  standard  deviation 

detconf 

f4 

f6.3 

102-107 

detection  snr  confidence 

freqex 

f4 

f6.2 

109-114 

Expected  frequency 

freqsd 

f4 

f6.2 

116-121 

frequence  standard  deviation 

freqconf 

f4 

f6.3 

123-128 

frequency  confidence 

velex 

f4 

f6.2 

130-135 

Expected  velocity 

velsd 

f4 

f6.2 

137-142 

velocity  standard  deviation 

velconf 

f4 

f6.3 

144-149 

velocity  confidence 

beam20Iex 

f4 

f6.2 

151-156 

Expected  rel.snr.beam  201 

beam201sd 

f4 

f6.2 

158-163 

standard  deviation,  beam  201 

beam201conf 

f4 

f6.3 

165-170 

confidence,  beam  201 

beam207ex 

f4 

f6.2 

172-177 

Expected  rel.snr,  beam  207 

beam207sd 

f4 

f6.2 

179-184 

standard  deviation,  beam  207 

beam207conf 

f4 

f6.3 

186-191 

confidence  beam  107 

beam254ex 

f4 

f6.2 

193-198 

Expected  rel.snr,  beem  254 

beam254sd 

f4 

f6.2 

200-205 

standard  deviation,  beam  254 

bcam254conf 

f4 

f6.3 

207-212 

confidence,  beam  254 

beam282ex 

f4 

f6.2 

214-219 

Expected  rel.snr,  beam  282 

bcam282sd 

f4 

f6.2 

221-226 

standard  deviation,  beam  282 

beam282conf 

f4 

f6.3 

228-233 

confidence,  beam  282 

beam310ex 

f4 

f6.2 

235-240 

Expected  rel.snr,  beam  310 

beam310sd 

f4 

f6.2 

242-247 

standard  deviation,  beam  310 

beam3I0conf 

f4 

f6.3 

249-254 

confidence,  beam  310 

beam312ex 

f4 

f6.2 

256-261 

Expected  rel.snr,  beam  312 

beam312sd 

f4 

f6.2 

263-268 

standard  deviation,  beam  312 

bcam312conf 

f4 

f6.3 

270-275 

confidence,  beam  312 

pname 

c4 

a4 

277-280 

Phase  name 

Iddate 

date 

a25 

282-306 

load  date 

limewgi 

f4 

f4.1 

308-311 

relative  time  weight 

aziwgt 

f4 

f4.1 

313-316 

azimuth  weight 

detweight 

f4 

f4.1 

318-321 

detection  rel  snr  weight 

freqwgt 

f4 

f4.1 

323-326 

frequency  weight 

velwgt 

f4 

f4.1 

328-331 

velocity  weight 

wgi201 

f4 

f4.1 

333-336 

beam  201  weight 

wgi207 

f4 

f4.1 

338-341 

beam  207  weight 

wgt254 

f4 

f4.1 

343-346 

beam  254  weight 

wgt282 

f4 

f4.1 

348-351 

beam  282  weight 

wgt310 

f4 

f4.1 

353-356 

beam  310  weight 

wgi312 

f4 

f4.1 

358-361 

beam  312  weight 
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phasematch  (continued) 

attribute 

name 

storage 

. type..... 

external 

format 

character 

positions 

attribute 

description 

staid 

c5 

a5 

363-367 

station  id 

pretime 

f8 

fl5.3 

369-383 

predicted  arrival  time 

pre201 

f8 

fll.5 

385-395 

predicted  201  snr 

pre207 

f8 

fll.5 

397^07 

predicted  207  snr 

pre254 

f8 

fll.5 

409419 

predicted  254  snr 

pre282 

f8 

fll.5 

421431 

predicted  282  snr 

prellO 

f8 

fll.5 

433-443 

predicted  310  snr 

pre312 

f8 

fll.5 

445455 

predicted  312  snr 

timeval 

f8 

f6.1 

457462 

measured  real  time 

azival 

f8 

f6.1 

464469 

measured  azimuth 

detval 

f8 

f6.1 

471476 

measured  detection  rel  sru 

freqval 

(8 

f6.1 

478483 

measured  frequency 

velval 

f8 

f6.1 

485490 

measured  velocity 

val201 

t8 

f6.1 

492497 

measured  201  relative  snr 

val207 

f8 

f6.1 

499-504 

measured  207  relative  snr 

val254 

f8 

f6.1 

506-511 

measured  254  relative  snr 

val282 

f8 

f6.i 

513-518 

measured  282  relauve  snr 

val310 

f8 

f6.1 

520-525 

measured  310  relative  snr 

val312 

f8 

f6.1 

527-532 

measured  312  relative  snr 

recipe 

auribute 

name 

storage 

type 

extental 

format 

character 

positions 

attribute 

description 

mame 

c20 

a20 

10-29 

recipe  name 

rid 

i4 

i8 

1-8 

recipe  id 

comm  id 

i4 

i8 

31-38 

comment  id 

datsw 

i4 

ilO 

4049 

data  switch 

foff 

i4 

ilO 

51-60 

byte  offset  in  file 

rectyp 

c4 

a4 

62-65 

recipe  type 

dir 

c30 

a30 

67-96 

recipe  directory 

hie 

c20 

a20 

98-117 

recipe  data  file 

Iddate 

date 

a25 

119-142 

load  date 

refjoc 

attribute 

name 

storage 

type 

external 

format 

character 

positions 

attribute 

description 

refid 

4 

i8 

1-8 

reference  location  id 

refnam 

cl6 

al6 

10-25 

reference  location  name 

lat 

f4 

f9.4 

27-35 

latitude 

Ion 

f4 

19.4 

3745 

longitude 

descrip 

c80 

a80 

47-126 

description 

Iddate 

date 

a25 

128-152 

load  date 
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sbsnr 

attribute 

name 

storage 

type 

external 

format 

character 

Dositions 

attribute 

description 

arid 

i4 

ig 

1-8 

arrival  id 

chid 

j4 

iS 

10-17 

channel  operation  id 

Slav 

f4 

fll.5 

19-29 

max  short  term  average  in  window 

Itav 

f4 

fll.5 

31-41 

long  term  average  at  detection  time 

Iddate 

date 

a25 

43-67 

load  date 

scriptmatch 

attribute 

name 

storage 

type. 

external 

format 

character 

positions 

attribute 

description 

matchid 

i4 

iS 

1-8 

SM/FCC  match  id 

orid 

i4 

iS 

10-17 

Assess  origin  id 

mconf 

f4 

n.5 

19-26 

Overall  match  confidence 

pconf 

f4 

n.5 

28-34 

Primary  match  confidence 

sconf 

f4 

n.5 

36-24 

Secondary  match  confidence 

mlat 

f4 

n.5 

44-52 

Matf'h  latitude 

mlong 

f4 

n.5 

54-62 

Match  longitude 

relabeled 

i2 

i4 

64-68 

Number  of  relabeled  phases 

missing 

i2 

i4 

70-74 

Number  of  missing  phases 

textexpl 

a25 

c25 

76-100 

Short  text  explanation 

Iddate 

c25 

a25 

102-126 

Load  date 

sigpro.time 

attribute 

name 

storage 
..  type 

external 

format 

character 

positions 

attribute 

description 

sta 

c6 

a6 

1-6 

station  code 

proctime 

f8 

fl5.3 

8-22 

consistent  peak  type  code 

Iddate 

date 

a25 

24-39 

load  date 

wftags 

attribute 

name 

storage 

ivpe 

external 

format 

character 

positions 

attribute 

description 

tagse 

i4 

i8 

1-8 

tag  switch 

tagid 

i4 

18 

10-17 

tag  id  (i.e.  orid) 

wfid 

i4 

i8 

19-26 

waveform  id 

Iddate 

date 

a25 

28-52 

load  date 
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